idnits 2.17.1 draft-newman-msgheader-originfo-00.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-23) 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 6 months document validity. ** 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 46: '...erable mailbox, and therefore MUST NOT...' RFC 2119 keyword, line 62: '...able mailbox and MUST NOT be used for ...' RFC 2119 keyword, line 74: '...tor-Info" header SHOULD be generated b...' RFC 2119 keyword, line 80: '...rom a given user MAY have different Or...' RFC 2119 keyword, line 84: '... Originator-Info MUST NOT be used for ...' (9 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 (December 1996) is 9991 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 103, but not defined == Missing Reference: 'RFC-822' is mentioned on line 159, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 977 (ref. 'NNTP') (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 822 (ref. 'IMESSAGE') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'SMTP-AUTH' Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 Mail Header Innosoft 4 Document: draft-newman-msgheader-originfo-00.txt December 1996 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. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. This 29 document will expire six months after publication. Distribution of 30 this draft is unlimited. 32 1. Introduction 34 This proposal is an attempt to provide a standard header to 35 indicate information about the message originator without implying 36 that there is a deliverable mailbox or mandating that internal 37 network information be revealed. The "Originator-Info" header is 38 intended to make the "X-Sender" and "X-X-Sender" headers obsolete. 40 Many mail clients on personal computers are now using a non- 41 standard "X-Sender" header to identify the originator of a message 42 without the implication that the sender has a known deliverable 43 mailbox (unlike the "Sender" header). Usually this "X-Sender" 44 header is constructed from the credentials used to login to a POP 45 [POP3], IMAP [IMAP4], or NNTP [NNTP] server. Such credentials 46 often do not refer to a deliverable mailbox, and therefore MUST NOT 47 be used to construct a return or reply address. 49 Unfortunately, some mailing list systems now use the "X-Sender" 50 header for authorization reply, or return messages. This causes 51 mis-delivery for systems where the login credentials do not refer 52 to a deliverable mailbox and leaves some users unable to 53 unsubscribe to certain mailing lists. Some clients have responded 54 to this problem by supporting an "X-X-Sender" header. This 55 situation is obviously problematic. 57 2. Originator-Info header 59 The Originator-Info header provides a list of attributes which may 60 be used to trace the originator of an Internet message [IMESSAGE]. 61 These attributes do not in any way imply the existance of a 62 deliverable mailbox and MUST NOT be used for authorization or to 63 construct a reply or return address. 65 Example: 67 From: Chris Newman 68 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu 70 This example indicates that a person whose identity can be 71 determined from the token "avsgl" was logged into the server 72 "cyrus.andrew.cmu.edu" when this message was composed. 74 An "Originator-Info" header SHOULD be generated by Internet mail 75 user agents (MUA) upon submission of an Internet message [IMESSAGE] 76 to a delivery system if the MUA is unable to verify the existance 77 of a deliverable mailbox for the current user and is authenticated 78 to an Internet service such as POP or IMAP. 80 Multiple messages from a given user MAY have different Originator- 81 Info headers, as that user may have access to multiple servers 82 and/or login identities. In addition, mail servers are renamed 83 more frequently than email addresses change. For these reasons, 84 Originator-Info MUST NOT be used for any purpose other than tracing 85 the originator of the message. Specifically, Originator-Info MUST 86 NOT be used to control access to mail based services, although such 87 services MAY record Originator-Info in log files. 89 2.1. "login-token" attribute 91 The login-token attribute is used to allow the identity of the 92 sender to be traced without explicitly revealing that identity. It 93 contains site-specific information which may be used to recover the 94 login-id (see section 2.2) of the originator. For example, it 95 might be constructed with an MD5 hash [MD5] of the login-id and a 96 site-specific secret. The login-token MAY use an algorithm which 97 produces a different token for each message. An Originator-Info 98 header SHOULD include a login-token attribute. 100 2.2. "login-id" attribute 102 The login-id attribute indicates the login identifier that was used 103 in a POP "USER" [POP3] or "AUTH" [POP3-AUTH] command or an IMAP 104 "LOGIN" or "AUTHENTICATE" [IMAP4] command. The login-id may also 105 be obtained from other services such as a Kerberos authentication 106 library. An Originator-Info header MAY include a login-id 107 attribute instead of a login-token attribute. A program 108 interpreting this header MUST NOT form an email address from the 109 "login-id" and "server" attributes. Such an address may not be 110 deliverable. 112 Example: 114 From: Chris Newman 115 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu 117 2.3. "server" attribute 119 The server attribute is a fully qualified Internet domain name 120 [DOM-NAME] of a mail server or other Internet server which the user 121 was authenticated to when the message was submitted. An 122 Originator-Info header SHOULD include a server attribute. 124 2.4. "token-authority" attribute 126 This attribute contains a human readable string providing 127 information about the individual or service that is capable of 128 translating the login-token. When absent, postmaster@ can 129 be assumed, where is the value of the server attribute. 131 Examples: 133 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 134 token-authority="nifty@cyrus.andrew.cmu.edu" 136 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 137 token-authority="Don't you recognize ROT13?" 139 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 140 token-authority="phone 555-555-5555, ask for Mr. Spook" 142 2.5. Other attributes 144 Other attributes MAY be used to provide additional information. 145 There is no requirement to register attributes as the Originator- 146 Info header is not intended for automated processing. For example, 147 an MUA on a Macintosh may wish to include the owner name as set in 148 the "Sharing Setup" control panel. 150 Example: 152 From: Chris Newman 153 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu; 154 MacOS-owner-name=nifty 156 3. ABNF for Originator-Info header 158 This defines the formal syntax for the "Originator-Info" header 159 using the notation defined in RFC 822 [RFC-822] and using terminals 160 defined in MIME [MIME-IMB]. 162 originator-info := "Originator-Info:" parameter *(";" parameter) 164 4. Security Considerations 166 The "Originator-Info" header is useful for traceing the source of 167 Internet messages. However, it contains no authenticated 168 information and is completely susceptible to spoofing by an 169 intelligent sender or intervening host. Therefore it is not a 170 substitute for authenticated delivery [SMTP-AUTH] and secure 171 message systems such as PGP-MIME [PGP-MIME]. 173 Some sites have concerns about revealing the names of internal 174 servers and login identities. MUAs could accomodate such sites 175 with an option to use the domain name of a SOCKS [SOCKS5] server 176 (or other firewall) in the "server" attribute instead of a private 177 mail server. Sites with no such considerations MAY use "login-id" 178 instead of "login-token". 180 5. References 182 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 183 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 185 187 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 188 RFC 1730, University of Washington, December 1994. 190 192 [NNTP] Kantor, Lapsley, "Network News Transfer Protocol: A Proposed 193 Standard for the Stream-Based Transmission of News", RFC 977, 194 U.C. San Diego, U.C. Berkeley, February 1986. 196 198 [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions 199 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, 200 First Virtual, November 1996. 202 204 [IMESSAGE] Crocker, D., "Standard for the Format of Arpa Internet Text 205 Messages", RFC 822, University of Delaware, August 1982. 207 209 [DOM-NAME] Mockapetris, P., "Domain Names - Implementation and 210 Specification", RFC 1035, ISI, November 1987 212 214 [MD5] Rivest, R. "The MD5 Message Digest Algorithm", 215 RFC 1321, MIT Laboratory for Computer Science, April, 1992. 217 219 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", 220 Work in Progress, Carnegie Mellon, October 1996. 222 [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", 223 RFC 2015, The Aerospace Corporation, October 1996. 225 227 [SOCKS5] Leech, Ganis, Lee, Kuris, Koblas, Jones, "SOCKS Protocol 228 Version 5", RFC 1928, Bell-Northern Research Ltd, International 229 Business Machines, NEC Systems Laboratory, Unify Corporation, 230 Hewlett-Packard Company, March 1996. 232 234 6. Author's Address 236 Chris Newman 237 Innosoft International, Inc. 238 1050 East Garvey Ave. South 239 West Covina, CA 91790 USA 241 Email: chris.newman@innosoft.com