idnits 2.17.1 draft-newman-msgheader-originfo-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1998) is 9471 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'POP3-AUTH' is mentioned on line 107, but not defined == Missing Reference: 'RFC-822' is mentioned on line 164, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 822 (ref. 'IMAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 977 (ref. 'NNTP') (Obsoleted by RFC 3977) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: Originator Info Message Header Innosoft 4 Document: draft-newman-msgheader-originfo-05.txt May 1998 6 Originator-Info Message Header 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 26 West Coast). 28 Introduction 30 This proposal is an attempt to provide a standard header to 31 indicate information about the message originator without implying 32 that there is a deliverable mailbox or mandating that internal 33 network information be revealed. The "Originator-Info" header is 34 intended to make the "X-Sender" and "X-X-Sender" headers obsolete. 36 Many mail clients on personal computers are now using a 37 non-standard "X-Sender" header to identify the originator of a 38 message without the implication that the sender has a known 39 deliverable mailbox (unlike the "Sender" header). Usually this 40 "X-Sender" header is constructed from the credentials used to login 41 to a POP [POP3], IMAP [IMAP4], or NNTP [NNTP] server. Such 42 credentials often do not refer to a deliverable mailbox, and 43 therefore MUST NOT be used to construct a return or reply address. 45 Unfortunately, some mailing list systems now use the "X-Sender" 46 header for authorization reply, or return messages. This causes 47 misdelivery for systems where the login credentials do not refer to 48 a deliverable mailbox and leaves some users unable to unsubscribe 49 to certain mailing lists. Some clients have responded to this 50 problem by supporting an "X-X-Sender" header. This situation is 51 obviously problematic. 53 1. Conventions Used in this Document 55 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 56 NOT", and "MAY" in this document are to be interpreted as described 57 in "Key words for use in RFCs to Indicate Requirement Levels" 58 [KEYWORDS]. 60 2. Originator-Info header 62 The Originator-Info header provides a list of attributes which may 63 be used to trace the originator of an Internet message [IMAIL]. 64 These attributes do not in any way imply the existence of a 65 deliverable mailbox and MUST NOT be used for authorization or to 66 construct a reply or return address. 68 Example: 70 From: Chris Newman 71 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu 73 This example indicates that a person whose identity can be 74 determined from the token "avsgl" was logged into the server 75 "cyrus.andrew.cmu.edu" when this message was composed. 77 An "Originator-Info" header SHOULD be generated by Internet mail 78 user agents (MUA) upon submission of an Internet message [IMAIL] to 79 a delivery system if the MUA is unable to verify the existence of a 80 deliverable mailbox for the current user and is authenticated to an 81 Internet service such as POP or IMAP. 83 Multiple messages from a given user MAY have different 84 Originator-Info headers, as that user may have access to multiple 85 servers and/or login identities. In addition, mail servers are 86 renamed more frequently than email addresses change. For these 87 reasons, Originator-Info MUST NOT be used for any purpose other 88 than tracing the originator of the message. Specifically, 89 Originator-Info MUST NOT be used to control access to mail based 90 services, although such services MAY record Originator-Info in log 91 files. 93 2.1. "login-token" attribute 95 The login-token attribute is used to allow the identity of the 96 sender to be traced without explicitly revealing that identity. It 97 contains site-specific information which may be used to recover the 98 login-id (see section 2.2) of the originator. For example, it 99 might be constructed with an MD5 hash [MD5] of the login-id and a 100 site-specific secret. The login-token MAY use an algorithm which 101 produces a different token for each message. An Originator-Info 102 header SHOULD include a login-token attribute. 104 2.2. "login-id" attribute 106 The login-id attribute indicates the login identifier that was used 107 in a POP "USER" [POP3] or "AUTH" [POP3-AUTH] command or an IMAP 108 "LOGIN" or "AUTHENTICATE" [IMAP4] command. The login-id may also 109 be obtained from other services such as a Kerberos authentication 110 library. An Originator-Info header MAY include a login-id 111 attribute instead of a login-token attribute. A program 112 interpreting this header MUST NOT form an email address from the 113 "login-id" and "server" attributes. Such an address may not be 114 deliverable. 116 Example: 118 From: Chris Newman 119 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu 121 2.3. "server" attribute 123 The server attribute is a fully qualified Internet domain name 124 [DOM-NAME] of a mail server or other Internet server which the user 125 was authenticated to when the message was submitted. An 126 Originator-Info header SHOULD include a server attribute. The 127 named server is encouraged to support applicable contact addresses 128 as specified in [MBOX-NAMES]. 130 2.4. "token-authority" attribute 132 This attribute contains a human readable string providing 133 information about the individual or service that is capable of 134 translating the login-token. 136 Examples: 138 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 139 token-authority="ask " 141 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 142 token-authority="Don't you recognize ROT13?" 144 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 145 token-authority="phone 555-555-5555, ask for Mr. Spook" 147 2.5. Other attributes 149 Other attributes MAY be used to provide additional information. 150 There is no requirement to register attributes as the 151 Originator-Info header is not intended for automated processing. 152 For example, an MUA on a Macintosh may wish to include the owner 153 name as set in the "Sharing Setup" control panel. 155 Example: 157 From: Chris Newman 158 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu; 159 MacOS-owner-name=nifty 161 3. ABNF for Originator-Info header 163 This defines the formal syntax for the "Originator-Info" header 164 using the ABNF notation defined in RFC 822 [RFC-822] and using 165 terminals defined in MIME [MIME-IMB]. 167 originator-info = "Originator-Info:" parameter *(";" parameter) 169 4. Security Considerations 171 The "Originator-Info" header is useful for tracing the source of 172 Internet messages. However, it contains no authenticated 173 information and is completely susceptible to spoofing by an 174 intelligent sender or intervening host. Therefore it is not a 175 substitute for secure message systems such as PGP-MIME [PGP-MIME]. 177 Some sites have concerns about revealing the names of internal 178 servers and login identities. MUAs could accommodate such sites 179 with an option to use the domain name of a SOCKS [SOCKS5] server 180 (or other firewall) in the "server" attribute instead of a private 181 mail server. Sites with no such considerations MAY use "login-id" 182 instead of "login-token". 184 5. Multinational Considerations 186 Parameters in character sets other than US-ASCII MAY use MIME 187 parameter extensions [MIME-PARAM]. This MAY also be used to 188 provide language labeling and continuations. 190 6. References 192 [DOM-NAME] Mockapetris, P., "Domain Names - Implementation and 193 Specification", RFC 1035, ISI, November 1987. 195 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 196 Messages", RFC 822, University of Delaware, August 1982. 198 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 199 4rev1", RFC 2060, University of Washington, December 1996. 201 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 202 Requirement Levels", RFC 2119, Harvard University, March 1997. 204 [MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles 205 and Functions", RFC 2142, Internet Mail Consortium, May 1997. 207 [MD5] Rivest, R. "The MD5 Message Digest Algorithm", RFC 1321, MIT 208 Laboratory for Computer Science, April 1992. 210 [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail 211 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 212 2045, Innosoft, First Virtual, November 1996. 214 [MIME-PARAM] Freed, Moore, "MIME Parameter Value and Encoded Word 215 Extensions: Character Sets, Languages, and Continuations", RFC 216 2231, Innosoft, University of Tennessee, November 1997. 218 [NNTP] Kantor, Lapsley, "Network News Transfer Protocol: A Proposed 219 Standard for the Stream-Based Transmission of News", RFC 977, U.C. 220 San Diego, U.C. Berkeley, February 1986. 222 [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy 223 (PGP)", RFC 2015, The Aerospace Corporation, October 1996. 225 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 226 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 228 [SOCKS5] Leech, Ganis, Lee, Kuris, Koblas, Jones, "SOCKS Protocol 229 Version 5", RFC 1928, Bell-Northern Research Ltd, International 230 Business Machines, NEC Systems Laboratory, Unify Corporation, 231 Hewlett-Packard Company, March 1996. 233 7. Author's Address 235 Chris Newman 236 Innosoft International, Inc. 237 1050 Lakes Drive 238 West Covina, CA 91790 USA 240 Email: chris.newman@innosoft.com