idnits 2.17.1 draft-newman-msgheader-originfo-01.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-25) 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 41: '...erable mailbox, and therefore MUST NOT...' RFC 2119 keyword, line 57: '...able mailbox and MUST NOT be used for ...' RFC 2119 keyword, line 69: '...tor-Info" header SHOULD be generated b...' RFC 2119 keyword, line 75: '...rom a given user MAY have different Or...' RFC 2119 keyword, line 79: '... Originator-Info MUST NOT be used for ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 1997) is 9781 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 98, but not defined == Missing Reference: 'RFC-822' is mentioned on line 153, 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 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'MIME-PARAM' ** Obsolete normative reference: RFC 977 (ref. 'NNTP') (Obsoleted by RFC 3977) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMTP-AUTH' Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 4 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-01.txt July 1997 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 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Introduction 29 This proposal is an attempt to provide a standard header to 30 indicate information about the message originator without implying 31 that there is a deliverable mailbox or mandating that internal 32 network information be revealed. The "Originator-Info" header is 33 intended to make the "X-Sender" and "X-X-Sender" headers obsolete. 35 Many mail clients on personal computers are now using a non- 36 standard "X-Sender" header to identify the originator of a message 37 without the implication that the sender has a known deliverable 38 mailbox (unlike the "Sender" header). Usually this "X-Sender" 39 header is constructed from the credentials used to login to a POP 40 [POP3], IMAP [IMAP4], or NNTP [NNTP] server. Such credentials 41 often do not refer to a deliverable mailbox, and therefore MUST NOT 42 be used to construct a return or reply address. 44 Unfortunately, some mailing list systems now use the "X-Sender" 45 header for authorization reply, or return messages. This causes 46 misdelivery for systems where the login credentials do not refer to 47 a deliverable mailbox and leaves some users unable to unsubscribe 48 to certain mailing lists. Some clients have responded to this 49 problem by supporting an "X-X-Sender" header. This situation is 50 obviously problematic. 52 1. Originator-Info header 54 The Originator-Info header provides a list of attributes which may 55 be used to trace the originator of an Internet message [IMAIL]. 56 These attributes do not in any way imply the existence of a 57 deliverable mailbox and MUST NOT be used for authorization or to 58 construct a reply or return address. 60 Example: 62 From: Chris Newman 63 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu 65 This example indicates that a person whose identity can be 66 determined from the token "avsgl" was logged into the server 67 "cyrus.andrew.cmu.edu" when this message was composed. 69 An "Originator-Info" header SHOULD be generated by Internet mail 70 user agents (MUA) upon submission of an Internet message [IMAIL] to 71 a delivery system if the MUA is unable to verify the existence of a 72 deliverable mailbox for the current user and is authenticated to an 73 Internet service such as POP or IMAP. 75 Multiple messages from a given user MAY have different Originator- 76 Info headers, as that user may have access to multiple servers 77 and/or login identities. In addition, mail servers are renamed 78 more frequently than email addresses change. For these reasons, 79 Originator-Info MUST NOT be used for any purpose other than tracing 80 the originator of the message. Specifically, Originator-Info MUST 81 NOT be used to control access to mail based services, although such 82 services MAY record Originator-Info in log files. 84 1.1. "login-token" attribute 86 The login-token attribute is used to allow the identity of the 87 sender to be traced without explicitly revealing that identity. It 88 contains site-specific information which may be used to recover the 89 login-id (see section 2.2) of the originator. For example, it 90 might be constructed with an MD5 hash [MD5] of the login-id and a 91 site-specific secret. The login-token MAY use an algorithm which 92 produces a different token for each message. An Originator-Info 93 header SHOULD include a login-token attribute. 95 1.2. "login-id" attribute 97 The login-id attribute indicates the login identifier that was used 98 in a POP "USER" [POP3] or "AUTH" [POP3-AUTH] command or an IMAP 99 "LOGIN" or "AUTHENTICATE" [IMAP4] command. The login-id may also 100 be obtained from other services such as a Kerberos authentication 101 library. An Originator-Info header MAY include a login-id 102 attribute instead of a login-token attribute. A program 103 interpreting this header MUST NOT form an email address from the 104 "login-id" and "server" attributes. Such an address may not be 105 deliverable. 107 Example: 109 From: Chris Newman 110 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu 112 1.3. "server" attribute 114 The server attribute is a fully qualified Internet domain name 115 [DOM-NAME] of a mail server or other Internet server which the user 116 was authenticated to when the message was submitted. An 117 Originator-Info header SHOULD include a server attribute. 119 1.4. "token-authority" attribute 121 This attribute contains a human readable string providing 122 information about the individual or service that is capable of 123 translating the login-token. When absent, postmaster@ can 124 be assumed, where is the value of the server attribute. 126 Examples: 128 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 129 token-authority="nifty@cyrus.andrew.cmu.edu" 131 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 132 token-authority="Don't you recognize ROT13?" 134 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 135 token-authority="phone 555-555-5555, ask for Mr. Spook" 137 1.5. Other attributes 138 Other attributes MAY be used to provide additional information. 139 There is no requirement to register attributes as the Originator- 140 Info header is not intended for automated processing. For example, 141 an MUA on a Macintosh may wish to include the owner name as set in 142 the "Sharing Setup" control panel. 144 Example: 146 From: Chris Newman 147 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu; 148 MacOS-owner-name=nifty 150 2. ABNF for Originator-Info header 152 This defines the formal syntax for the "Originator-Info" header 153 using the notation defined in RFC 822 [RFC-822] and using terminals 154 defined in MIME [MIME-IMB]. 156 originator-info := "Originator-Info:" parameter *(";" parameter) 158 3. Security Considerations 160 The "Originator-Info" header is useful for tracing the source of 161 Internet messages. However, it contains no authenticated 162 information and is completely susceptible to spoofing by an 163 intelligent sender or intervening host. Therefore it is not a 164 substitute for authenticated delivery [SMTP-AUTH] and secure 165 message systems such as PGP-MIME [PGP-MIME]. 167 Some sites have concerns about revealing the names of internal 168 servers and login identities. MUAs could accommodate such sites 169 with an option to use the domain name of a SOCKS [SOCKS5] server 170 (or other firewall) in the "server" attribute instead of a private 171 mail server. Sites with no such considerations MAY use "login-id" 172 instead of "login-token". 174 4. Multinational Considerations 176 Parameters in character sets other than US-ASCII MAY use MIME 177 parameter extensions [MIME-PARAM]. This MAY also be used to 178 provide language labeling and continuations. 180 5. References 182 [DOM-NAME] Mockapetris, P., "Domain Names - Implementation and 183 Specification", RFC 1035, ISI, November 1987. 185 187 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 188 Messages", RFC 822, University of Delaware, August 1982. 190 192 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 193 RFC 1730, University of Washington, December 1994. 195 197 [MD5] Rivest, R. "The MD5 Message Digest Algorithm", 198 RFC 1321, MIT Laboratory for Computer Science, April 1992. 200 202 [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions 203 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, 204 First Virtual, November 1996. 206 208 [MIME-PARAM] Freed, Moore, "MIME Parameter Value and Encoded Word 209 Extensions: Character Sets, Languages, and Continuations", RFC XXXX, 210 Innosoft, University of Tennessee, March 1997. 212 [NNTP] Kantor, Lapsley, "Network News Transfer Protocol: A Proposed 213 Standard for the Stream-Based Transmission of News", RFC 977, 214 U.C. San Diego, U.C. Berkeley, February 1986. 216 218 [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", 219 RFC 2015, The Aerospace Corporation, October 1996. 221 223 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 224 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 226 228 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 229 Work in Progress, February 1997. 231 [SOCKS5] Leech, Ganis, Lee, Kuris, Koblas, Jones, "SOCKS Protocol 232 Version 5", RFC 1928, Bell-Northern Research Ltd, International 233 Business Machines, NEC Systems Laboratory, Unify Corporation, 234 Hewlett-Packard Company, March 1996. 236 238 6. Author's Address 240 Chris Newman 241 Innosoft International, Inc. 242 1050 Lakes Drive 243 West Covina, CA 91790 USA 245 Email: chris.newman@innosoft.com