idnits 2.17.1 draft-ietf-marid-pra-00.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 222. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (August 2004) is 7193 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) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARID Working Group J. Lyon 2 Internet Draft Microsoft Corp 3 Document: draft-ietf-marid-pra-00.txt 4 Expires: February 2005 August 2004 6 Purported Responsible Address in E-Mail Messages 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 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 The 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 Purported Responsible Address in E-Mail Messages August 2004 40 Table of Contents 42 1. Introduction...................................................2 43 2. Determining the Purported Responsible Address..................3 44 3. Security Considerations........................................4 45 4. IANA Considerations............................................4 46 5. Acknowledgements...............................................4 47 6. References.....................................................4 48 6.1 Normative References.......................................4 49 6.2 Informative References.....................................5 50 7. Author's Address...............................................5 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 1. Introduction 60 Most E-Mail flows relatively directly from a sender to a recipient, 61 with a small number of Mail Transfer Agents (MTAs) in between. Some 62 messages, however, are resent by forwarding agents, mailing list 63 servers, and other such software. These messages effectively result 64 in two or more mail transactions: one from the sender to the 65 forwarding agent, and another from the agent to the destination. 67 In some cases, messages travel through more than one of these agents. 68 This can occur, for example, when one mailing list is subscribed to 69 another, or when the address subscribed to a mailing list is a 70 forwarding service. 72 Further complicating the situation, in some cases the party that 73 introduces a message is not the author of the message. For example, 74 many news web sites have a "Mail this article" function that the 75 public can use to e-mail a copy of the article to a friend. In this 76 case, the mail is "from" the person who pressed the button, but is 77 physically sent by the operator of the web site. 79 This document describes an algorithm that allows one to determine who 80 appears to have most recently caused an e-mail message to be 81 delivered. It does this by inspecting the headers in the message. 82 [RFC2822] contains a detailed specification of all of the relevant 83 headers. 85 Note that the results of this algorithm are only as truthful as the 86 headers contained in the message; if a message contains fraudulent or 87 incorrect headers, this algorithm will yield an incorrect result. 89 Purported Responsible Address in E-Mail Messages August 2004 91 For this reason, the result of the algorithm is called the "Purported 92 Responsible Address" -- "purported" because it tells you what a 93 message claims about where it came from, but not necessarily where it 94 actually came from. 96 This document does not prescribe any particular uses for the 97 Purported Responsible Address. However, [SenderID] describes a 98 method of determining whether a particular MTA is authorized to send 99 mail on behalf of the domain contained in the PRA. 101 2. Determining the Purported Responsible Address 103 The purported responsible address (PRA) of a message is determined by 104 the following algorithm: 106 1. Locate the first non-empty Resent-Sender header in the message. 107 If no such header is found, continue with step 2. If it is 108 preceded by a non-empty Resent-From header and one or more 109 Received or Return-Path headers occur after said Resent-From 110 header and before the Resent-Sender header, continue with step 111 2. Otherwise, proceed to step 5. 113 2. Locate the first non-empty Resent-From header in the message. 114 If a Resent-From header is found, proceed to step 5. Otherwise, 115 continue with step 3. 117 3. Locate all the non-empty Sender headers in the message. If 118 there are no such headers, continue with step 4. If there is 119 exactly one such header, proceed to step 5. If there is more 120 than one such header, proceed to step 6. 122 4. Locate all the non-empty From headers in the message. If there 123 is exactly one such header, continue with step 5. Otherwise, 124 proceed to step 6. 126 5. A previous step has selected a single header from the message. 127 If that header is malformed (e.g. it appears to contain multiple 128 mailboxes, or the single mailbox is hopelessly malformed, or the 129 single mailbox does not contain a domain name), continue with 130 step 6. Otherwise, return that single mailbox as the Purported 131 Responsible Address. 133 6. The message is ill-formed, and it is impossible to determine a 134 Purported Responsible Address. 136 Note that what constitutes a hopelessly malformed header or a 137 hopelessly malformed mailbox in step 5 above is a matter for local 138 Purported Responsible Address in E-Mail Messages August 2004 140 policy. Such local policy will never cause two implementations to 141 return different PRAs. However it may cause one implementation to 142 return a PRA where another implementation does not. This will only 143 occur when dealing with a message containing headers of questionable 144 legality. 146 Note that steps 1 and 2 above extract the Resent-Sender or Resent- 147 From header from the first resent block (as defined by section 3.6.6 148 of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From 149 header if there are no resent blocks. 151 3. Security Considerations 153 The PRA, as described by this document, is extracted from message 154 headers that have historically not been verified. Thus, anyone using 155 the PRA for any purpose MUST be aware that the headers from which is 156 is derived might be fraudulent, malicious, malformed and/or 157 incorrect. [SenderID] describes one mechanism for validating the 158 PRA. 160 4. IANA Considerations 162 This document contains no actions for IANA. 164 5. Acknowledgements 166 The PRA concept was first published in [CallerID]. It as been 167 refined using valuable suggestions from members of the MARID working 168 group. 170 6. References 172 6.1 Normative References 174 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 175 Requirement Levels", RFC 2119. 177 [RFC2822] P. Resnick (editor), "Internet Message Format", RFC 2822. 179 Purported Responsible Address in E-Mail Messages August 2004 181 6.2 Informative References 183 [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical 184 Specification, 185 http://www.microsoft.com/mscorp/twc/privacy/spam_callerid 186 .mspx. 188 [SenderID] J. Lyon and M. Wong, "Sender ID: Authenticating E-Mail", 189 draft-ietf-marid-core-03. Work in progress. 191 7. Author's Address 193 Jim Lyon 194 Microsoft Corporation 195 One Microsoft Way 196 Redmond, WA 98052 197 USA 198 jimlyon@microsoft.com 200 Intellectual Property Statement 202 The IETF takes no position regarding the validity or scope of any 203 Intellectual Property Rights or other rights that might be claimed to 204 pertain to the implementation or use of the technology described in 205 this document or the extent to which any license under such rights 206 might or might not be available; nor does it represent that it has 207 made any independent effort to identify any such rights. Information 208 on the procedures with respect to rights in RFC documents can be 209 found in BCP 78 and BCP 79. 211 Copies of IPR disclosures made to the IETF Secretariat and any 212 assurances of licenses to be made available, or the result of an 213 attempt made to obtain a general license or permission for the use of 214 such proprietary rights by implementers or users of this 215 specification can be obtained from the IETF on-line IPR repository at 216 http://www.ietf.org/ipr. 218 The IETF invites any interested party to bring to its attention any 219 copyrights, patents or patent applications, or other proprietary 220 rights that may cover technology that may be required to implement 221 this standard. Please address the information to the IETF at ietf- 222 ipr@ietf.org. 224 Purported Responsible Address in E-Mail Messages August 2004 226 Disclaimer of Validity 228 This document and the information contained herein are provided on an 229 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 230 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 231 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 232 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 233 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 234 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 236 Copyright Statement 238 Copyright (C) The Internet Society (2004). This document is subject 239 to the rights, licenses and restrictions contained in BCP 78, and 240 except as set forth therein, the authors retain all their rights. 242 Acknowledgment 244 Funding for the RFC Editor function is currently provided by the 245 Internet Society.