idnits 2.17.1 draft-lyon-senderid-pra-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 241. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 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 2005) is 6893 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Lyon 3 Category: Experimental Microsoft Corp 4 Document: draft-lyon-senderid-pra-01.txt May 2005 6 Purported Responsible Address in E-Mail Messages 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than a "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document defines an algorithm by which, given an e-mail message, 34 one can extract the identity of the party that appears to have most 35 proximately caused that message to be delivered. This identity is 36 called the "Purported Responsible Address" (PRA). 38 Table of Contents 40 1. Introduction...................................................2 41 2. Determining the Purported Responsible Address..................3 42 3. Security Considerations........................................4 43 4. IANA Considerations............................................5 44 5. Acknowledgements...............................................5 45 6. References.....................................................5 46 6.1 Normative References.......................................5 47 6.2 Informative References.....................................5 48 7. Author's Address...............................................5 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 1. Introduction 58 Most e-Mail flows relatively directly from a sender to a recipient, 59 with a small number of Mail Transfer Agents (MTAs) in between. Some 60 messages, however, are resent by forwarding agents, mailing list 61 servers, and other such software. These messages effectively result 62 in two or more mail transactions: one from the sender to the 63 forwarding agent, and another from the agent to the destination. 65 In some cases, messages travel through more than one of these agents. 66 This can occur, for example, when one mailing list is subscribed to 67 another, or when the address subscribed to a mailing list is a 68 forwarding service. 70 Further complicating the situation, in some cases the party that 71 introduces a message is not the author of the message. For example, 72 many news web sites have a "Mail this article" function that the 73 public can use to e-mail a copy of the article to a friend. In this 74 case, the mail is "from" the person who pressed the button, but is 75 physically sent by the operator of the web site. 77 This document defines a new identity associated with an e-mail 78 message, called the Purported Responsible Address (PRA), which is 79 determined by inspecting the header of the message. The PRA is 80 designed to be the entity that (according to the header) most 81 recently caused the message to be delivered. 83 Note that the results of this algorithm are only as truthful as the 84 headers contained in the message; if a message contains fraudulent or 85 incorrect headers, this algorithm will yield an incorrect result. 86 For this reason, the result of the algorithm is called the "Purported 87 Responsible Address" -- "purported" because it tells you what a 88 message claims about where it came from, but not necessarily where it 89 actually came from. 91 This document does not prescribe any particular uses for the 92 Purported Responsible Address. However, [SenderID] describes a 93 method of determining whether a particular MTA is authorized to send 94 mail on behalf of the domain contained in the PRA. 96 2. Determining the Purported Responsible Address 98 The purported responsible address (PRA) of a message is determined by 99 the following algorithm: 101 1. Select the first non-empty Resent-Sender header in the message. If 102 no such header is found, continue with step 2. If it is preceded 103 by a non-empty Resent-From header and one or more Received or 104 Return-Path headers occur after said Resent-From header and before 105 the Resent-Sender header, continue with step 2. Otherwise, 106 proceed to step 5. 108 2. Select the first non-empty Resent-From header in the message. If 109 a Resent-From header is found, proceed to step 5. Otherwise, 110 continue with step 3. 112 3. Select all the non-empty Sender headers in the message. If there 113 are no such headers, continue with step 4. If there is exactly 114 one such header, proceed to step 5. If there is more than one 115 such header, proceed to step 6. 117 4. Select all the non-empty From headers in the message. If there is 118 exactly one such header, continue with step 5. Otherwise, proceed 119 to step 6. 121 5. A previous step has selected a single header from the message. If 122 that header is malformed (e.g. it appears to contain multiple 123 mailboxes, or the single mailbox is hopelessly malformed, or the 124 single mailbox does not contain a domain name), continue with step 125 6. Otherwise, return that single mailbox as the Purported 126 Responsible Address. 128 6. The message is ill-formed, and it is impossible to determine a 129 Purported Responsible Address. 131 For the purposes of this algorithm, a header field is "non-empty" if 132 and only if it contains any non-whitespace characters. Header fields 133 that are otherwise relevant but contain only whitespace are ignored 134 and treated as if they were not present. 136 Note that steps 1 and 2 above extract the Resent-Sender or Resent- 137 From header from the first resent block (as defined by section 3.6.6 138 of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From 139 header if there are no resent blocks. 141 Note that what constitutes a hopelessly malformed header or a 142 hopelessly malformed mailbox in step 5 above is a matter for local 143 policy. Such local policy will never cause two implementations to 144 return different PRAs. However it may cause one implementation to 145 return a PRA where another implementation does not. This will only 146 occur when dealing with a message containing headers of questionable 147 legality. 149 Although the algorithm specifies how messages that are not in strict 150 conformance with the provisions of RFC2822 should be treated for the 151 purposes of determining the PRA, this should not be taken as 152 requiring or recommending that any systems accept such messages when 153 they otherwise would not have done so. However, if a liberal 154 implementation accepts such messages and desires to know their PRA, 155 it MUST use the algorithm specified here. 157 Where messages conform to RFC822 rather than RFC2822, it is possible 158 for the algorithm to give unexpected results. An RFC822 message 159 should not normally contain more than one set of resent headers; 160 however the placement of those headers is not specified, nor are they 161 required to be contiguous. It is hence possible that the Resent-From 162 header will be selected even though a Resent-Sender header is 163 present. Such cases are expected to be rare or non-existent in 164 practice. 166 3. Security Considerations 168 The PRA, as described by this document, is extracted from message 169 headers that have historically not been verified. Thus, anyone using 170 the PRA for any purpose MUST be aware that the headers from which it 171 is derived might be fraudulent, malicious, malformed and/or 172 incorrect. [SenderID] describes one mechanism for validating the 173 PRA. 175 A message's PRA will often be extracted from a header field that is 176 not normally displayed by existing mail user agent software. If the 177 PRA is used as part of a mechanism to authenticate the message's 178 origin, the message SHOULD NOT be displayed with an indication of its 179 authenticity (positive or negative) without the PRA header field also 180 being displayed. 182 4. IANA Considerations 184 This document contains no actions for IANA. 186 5. Acknowledgements 188 The PRA concept was first published in [CallerID]. It as been 189 refined using valuable suggestions from members of the MARID working 190 group. 192 6. References 194 6.1 Normative References 196 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 197 Requirement Levels", RFC 2119. 199 [RFC2822] P. Resnick (editor), "Internet Message Format", RFC 2822. 201 6.2 Informative References 203 [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical 204 Specification, http://www.microsoft.com/mscorp/twc/ 205 privacy/spam_callerid.mspx. 207 [SenderID] J. Lyon and M. Wong, "Sender ID: Authenticating E-Mail", 208 draft-lyon-senderid-core-01. Work in progress. 210 7. Author's Address 212 Jim Lyon 213 Microsoft Corporation 214 One Microsoft Way 215 Redmond, WA 98052 216 USA 217 jimlyon@microsoft.com 219 Intellectual Property Statement 221 The IETF takes no position regarding the validity or scope of any 222 Intellectual Property Rights or other rights that might be claimed to 223 pertain to the implementation or use of the technology described in 224 this document or the extent to which any license under such rights 225 might or might not be available; nor does it represent that it has 226 made any independent effort to identify any such rights. Information 227 on the procedures with respect to rights in RFC documents can be 228 found in BCP 78 and BCP 79. 230 Copies of IPR disclosures made to the IETF Secretariat and any 231 assurances of licenses to be made available, or the result of an 232 attempt made to obtain a general license or permission for the use of 233 such proprietary rights by implementers or users of this 234 specification can be obtained from the IETF on-line IPR repository at 235 http://www.ietf.org/ipr. 237 The IETF invites any interested party to bring to its attention any 238 copyrights, patents or patent applications, or other proprietary 239 rights that may cover technology that may be required to implement 240 this standard. Please address the information to the IETF at ietf- 241 ipr@ietf.org. 243 Disclaimer of Validity 245 This document and the information contained herein are provided on an 246 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 247 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 248 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 249 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 250 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 253 Copyright Statement 255 Copyright (C) The Internet Society (2005). This document is subject 256 to the rights, licenses and restrictions contained in BCP 78, and 257 except as set forth therein, the authors retain all their rights. 259 Acknowledgment 261 Funding for the RFC Editor function is currently provided by the 262 Internet Society.