idnits 2.17.1 draft-newman-msgheader-originfo-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (November 1997) is 9652 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 112, but not defined == Missing Reference: 'RFC-822' is mentioned on line 169, 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') ** Obsolete normative reference: RFC 977 (ref. 'NNTP') (Obsoleted by RFC 3977) Summary: 14 errors (**), 0 flaws (~~), 6 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-03.txt November 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 Copyright Notice 29 Copyright (C) The Internet Society 1997. All Rights Reserved. 31 Introduction 33 This proposal is an attempt to provide a standard header to 34 indicate information about the message originator without implying 35 that there is a deliverable mailbox or mandating that internal 36 network information be revealed. The ''Originator-Info'' header is 37 intended to make the ''X-Sender'' and ''X-X-Sender'' 38 headers obsolete. 40 Many mail clients on personal computers are now using a 41 non-standard ''X-Sender'' header to identify the originator of a 42 message without the implication that the sender has a known 43 deliverable mailbox (unlike the ''Sender'' header). Usually this 44 ''X-Sender'' header is constructed from the credentials 45 used to login to a POP [POP3], IMAP [IMAP4], or 46 NNTP [NNTP] server. Such credentials often do not refer 47 to a deliverable mailbox, and 48 therefore MUST NOT be used to construct a return or reply address. 50 Unfortunately, some mailing list systems now use the ''X-Sender'' 51 header for authorization reply, or return messages. This causes 52 misdelivery for systems where the login credentials do not refer to 53 a deliverable mailbox and leaves some users unable to unsubscribe 54 to certain mailing lists. Some clients have responded to this 55 problem by supporting an ''X-X-Sender'' header. This situation is 56 obviously problematic. 58 1. Conventions Used in this Document 60 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 61 NOT", and "MAY" in this document are to be interpreted as described 62 in "Key words for use in RFCs to Indicate Requirement Levels" 63 [KEYWORDS]. 65 2. Originator-Info header 67 The Originator-Info header provides a list of attributes which may 68 be used to trace the originator of an Internet message [IMAIL]. 69 These attributes do not in any way imply the existence of a 70 deliverable mailbox and MUST NOT be used for authorization or to 71 construct a reply or return address. 73 Example: 75 From: Chris Newman 76 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu 78 This example indicates that a person whose identity can be 79 determined from the token "avsgl" was logged into the server 80 "cyrus.andrew.cmu.edu" when this message was composed. 82 An "Originator-Info" header SHOULD be generated by Internet mail 83 user agents (MUA) upon submission of an Internet message [IMAIL] to 84 a delivery system if the MUA is unable to verify the existence of a 85 deliverable mailbox for the current user and is authenticated to an 86 Internet service such as POP or IMAP. 88 Multiple messages from a given user MAY have different 89 Originator-Info headers, as that user may have access to multiple 90 servers and/or login identities. In addition, mail servers are 91 renamed more frequently than email addresses change. For these 92 reasons, Originator-Info MUST NOT be used for any purpose other 93 than tracing the originator of the message. Specifically, 94 Originator-Info MUST NOT be used to control access to mail based 95 services, although such services MAY record Originator-Info in log 96 files. 98 2.1. "login-token" attribute 100 The login-token attribute is used to allow the identity of the 101 sender to be traced without explicitly revealing that identity. It 102 contains site-specific information which may be used to recover the 103 login-id (see section 2.2) of the originator. For example, it 104 might be constructed with an MD5 hash [MD5] of the login-id and a 105 site-specific secret. The login-token MAY use an algorithm which 106 produces a different token for each message. An Originator-Info 107 header SHOULD include a login-token attribute. 109 2.2. "login-id" attribute 111 The login-id attribute indicates the login identifier that was used 112 in a POP "USER" [POP3] or "AUTH" [POP3-AUTH] command or an IMAP 113 "LOGIN" or "AUTHENTICATE" [IMAP4] command. The login-id may also 114 be obtained from other services such as a Kerberos authentication 115 library. An Originator-Info header MAY include a login-id 116 attribute instead of a login-token attribute. A program 117 interpreting this header MUST NOT form an email address from the 118 "login-id" and "server" attributes. Such an address may not be 119 deliverable. 121 Example: 123 From: Chris Newman 124 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu 126 2.3. "server" attribute 128 The server attribute is a fully qualified Internet domain name 129 [DOM-NAME] of a mail server or other Internet server which the user 130 was authenticated to when the message was submitted. An 131 Originator-Info header SHOULD include a server attribute. The 132 named server is encouraged to support applicable contact addresses 133 as specified in [MBOX-NAMES]. 135 2.4. "token-authority" attribute 137 This attribute contains a human readable string providing 138 information about the individual or service that is capable of 139 translating the login-token. 141 Examples: 143 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 144 token-authority="ask " 146 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 147 token-authority="Don't you recognize ROT13?" 149 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; 150 token-authority="phone 555-555-5555, ask for Mr. Spook" 152 2.5. Other attributes 154 Other attributes MAY be used to provide additional information. 155 There is no requirement to register attributes as the 156 Originator-Info header is not intended for automated processing. 157 For example, an MUA on a Macintosh may wish to include the owner 158 name as set in the "Sharing Setup" control panel. 160 Example: 162 From: Chris Newman 163 Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu; 164 MacOS-owner-name=nifty 166 3. ABNF for Originator-Info header 168 This defines the formal syntax for the "Originator-Info" header 169 using the ABNF notation defined in RFC 822 [RFC-822] and using 170 terminals defined in MIME [MIME-IMB]. 172 originator-info := "Originator-Info:" parameter *(";" parameter) 174 4. Security Considerations 176 The "Originator-Info" header is useful for tracing the source of 177 Internet messages. However, it contains no authenticated 178 information and is completely susceptible to spoofing by an 179 intelligent sender or intervening host. Therefore it is not a 180 substitute for secure message systems such as PGP-MIME [PGP-MIME]. 182 Some sites have concerns about revealing the names of internal 183 servers and login identities. MUAs could accommodate such sites 184 with an option to use the domain name of a SOCKS [SOCKS5] server 185 (or other firewall) in the "server" attribute instead of a private 186 mail server. Sites with no such considerations MAY use "login-id" 187 instead of "login-token". 189 5. Multinational Considerations 191 Parameters in character sets other than US-ASCII MAY use MIME 192 parameter extensions [MIME-PARAM]. This MAY also be used to 193 provide language labeling and continuations. 195 6. References 197 [DOM-NAME] Mockapetris, P., "Domain Names - Implementation and 198 Specification", RFC 1035, ISI, November 1987. 200 202 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text 203 Messages", RFC 822, University of Delaware, August 1982. 205 207 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 208 4", RFC 1730, University of Washington, December 1994. 210 212 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 213 Requirement Levels", RFC 2119, Harvard University, March 1997. 215 217 [MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles 218 and Functions", RFC 2142, Internet Mail Consortium, May 1997. 220 222 [MD5] Rivest, R. "The MD5 Message Digest Algorithm", RFC 1321, MIT 223 Laboratory for Computer Science, April 1992. 225 227 [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail 228 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 229 2045, Innosoft, First Virtual, November 1996. 231 233 [MIME-PARAM] Freed, Moore, "MIME Parameter Value and Encoded Word 234 Extensions: Character Sets, Languages, and Continuations", RFC 235 2231, Innosoft, University of Tennessee, November 1997. 237 239 [NNTP] Kantor, Lapsley, "Network News Transfer Protocol: A Proposed 240 Standard for the Stream-Based Transmission of News", RFC 977, U.C. 241 San Diego, U.C. Berkeley, February 1986. 243 245 [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy 246 (PGP)", RFC 2015, The Aerospace Corporation, October 1996. 248 250 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 251 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 253 255 [SOCKS5] Leech, Ganis, Lee, Kuris, Koblas, Jones, "SOCKS Protocol 256 Version 5", RFC 1928, Bell-Northern Research Ltd, International 257 Business Machines, NEC Systems Laboratory, Unify Corporation, 258 Hewlett-Packard Company, March 1996. 260 262 7. Full Copyright Statement 264 Copyright (C) The Internet Society 1997. All Rights Reserved. 266 This document and translations of it may be copied and furnished to 267 others, and derivative works that comment on or otherwise explain 268 it or assist in its implmentation may be prepared, copied, 269 published and distributed, in whole or in part, without restriction 270 of any kind, provided that the above copyright notice and this 271 paragraph are included on all such copies and derivative works. 272 However, this document itself may not be modified in any way, such 273 as by removing the copyright notice or references to the Internet 274 Society or other Internet organizations, except as needed for the 275 purpose of developing Internet standards in which case the 276 procedures for copyrights defined in the Internet Standards process 277 must be followed, or as required to translate it into languages 278 other than English. 280 The limited permissions granted above are perpetual and will not be 281 revoked by the Internet Society or its successors or assigns. 283 This document and the information contained herein is provided on 284 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 285 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 286 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 287 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 290 8. Author's Address 292 Chris Newman 293 Innosoft International, Inc. 294 1050 Lakes Drive 295 West Covina, CA 91790 USA 297 Email: chris.newman@innosoft.com