idnits 2.17.1 draft-ietf-marid-csv-dna-02.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 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 141: '...ing SMTP clients SHOULD advertise list...' RFC 2119 keyword, line 143: '... those servers MAY consult any accre...' RFC 2119 keyword, line 145: '...ding SMTP client SHOULD register accre...' RFC 2119 keyword, line 147: '...ces. The client SHOULD place such rec...' RFC 2119 keyword, line 151: '... records MAY be used....' (14 more instances...) 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 (February 20, 2005) is 7002 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) == Unused Reference: 'ID-Marid-CSV' is defined on line 332, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-Marid-CSV' ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARID J. Leslie 2 Internet-Draft JLC.net 3 Expires: August 24, 2005 D. Crocker 4 Brandenburg InternetWorking 5 D. Otis 6 Mail Abuse Prevention System 7 February 20, 2005 9 Domain Name Accreditation (DNA) 10 draft-ietf-marid-csv-dna-02 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 24, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 Increased diversity and abuse of access, across the open Internet, 46 mandates additional accountability for sending SMTP clients, in the 47 absence of prior, direct arrangement with receiving SMTP servers. 49 One means for enabling this is by registration with third-party 50 services that vouch for the policies and accountability of SMTP 51 clients accessing SMTP servers. This specification defines a means 52 for an SMTP client to list third-party services that are prepared to 53 vouch for it, and a means for an SMTP server, or its intermediary, to 54 query vouching services. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Accreditation Services . . . . . . . . . . . . . . . . . . . 4 61 4. Listing Pointer Service Record Template . . . . . . . . . . 5 62 5. Accreditation Procedure . . . . . . . . . . . . . . . . . . 5 63 6. Accreditation Report Record Template . . . . . . . . . . . . 6 64 7. Discussion of DNS record types . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 66 9. References - Normative . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . 10 70 1. Introduction 72 The Internet mail system, based on SMTP [RFC2821], is designed to 73 allow any client to contact any server. Where prior arrangement is 74 appropriate and may be verified during the session, the client and 75 server can use classic authentication techniques. Increased 76 diversity and abuse of access mandates additional accountability and 77 validation for sessions that do not have the benefit of prior, direct 78 arrangement. One means for enabling this is by having the sending 79 SMTP client registered with a third-party accreditation service that 80 can provide an independent path to information about the policies and 81 performance quality of that client's operator. 83 This specification defines a mechanism for obtaining such 84 information. It can be operated directly, between the receiving SMTP 85 server and individual direct accreditation services, or it can be 86 used with an indirect/proxy accreditation server working on behalf of 87 the SMTP server, fielding queries to other accreditation services. 89 The Domain Name Service [RFC1035] provides a common registration 90 environment, so that sending SMTP clients can specify third-party 91 services in which they are listed. The DNS also provides a 92 convenient venue for listing the accreditation information reported 93 by those services. 95 2. Background 97 Should a sending SMTP client host (or network) be trusted to be 98 transmit genuine email, rather than problematic messages, such as 99 spam and worms? There are many third-party services that publish 100 their assessments of such hosts and networks. For example, The 101 MAPS-RBL Realtime Blackhole List was established in 1996, listing IP 102 addresses of SMTP clients which sent large amounts of unsolicited 103 email. Another well-known service was ORBS, which listed SMTP 104 clients verified to act as open relays, thereby forwarding mail 105 without any attempt at validation of the sender. 107 Less well-known are various "whitelist" services, which list SMTP 108 clients assessed to be sending little or no spam. One examples is 109 bondedsender.com; it lists IP addresses of SMTP clients whose owners 110 have posted a bond with bondedsender.com. Each time a recipient of 111 an email passing through one of the bonded SMTP clients complains 112 that the email actually was spam, a portion of that bond is forfeit 113 to a non-profit organization. Another example is Habeas.com, 114 authorizing senders to include a copyrighted text string, to show 115 certification. 117 3. Accreditation Services 119 Third-party services can list sending SMTP clients that guard against 120 sending unsolicited bulk email or they can list those that are known 121 to be a problem. This provides a mechanism for establishing trust 122 between clients and servers that have had no prior contact. This 123 specification does not deal with the internal operation of such 124 third-party services. 126 Accreditation services must, themselves, be assessed for the criteria 127 they use. Some will have trivial criteria, offering no serious 128 quality assurance. Others will be so strict as to have very narrow 129 utility. Still others may use criteria that go wildly astray from a 130 sender's care in obtaining and using recipient addresses. For 131 example the accreditation service might base their assessment on the 132 listee's political views. Hence it is the responsibility of the host 133 querying the accreditation service to evaluate the operation of the 134 accreditation service, itself, and treat the weightings they offer 135 accordingly. 137 Finding Appropriate Accreditation Services: With millions of domains 138 and hundreds of expected accreditation services, a core challenge 139 is to find the particular direct accreditation services that 140 evaluate a particular sending SMTP client. For that reason, 141 sending SMTP clients SHOULD advertise lists in which they appear. 142 This is intended as a convenience for receiving SMTP servers, and 143 those servers MAY consult any accreditation services they wish. 145 A sending SMTP client SHOULD register accreditation services in 146 which it is listed by including DNS records with domain-names of 147 the accreditation services. The client SHOULD place such records 148 at each sub-domain level that receiving SMTP servers will need to 149 validate. In cases where the domain management wishes to 150 advertise the same list for any subdomain name, wildcard DNS 151 records MAY be used. 153 (Note that the existence of these DNS records does not certify 154 that a sending SMTP client has a valid claim to the name it places 155 in the EHLO command; this requires a separate mechanism, to ensure 156 that the client is authorized to use that name. 158 Clients SHOULD list more than one accreditation service, so that 159 it is likely at least one service will be acceptable to a 160 receiving SMTP server that is making the query. Indeed, it is 161 likely that some direct accreditation services will develop a 162 reputation for being "spam-friendly" and be considered worthless 163 for reputation purposes. In other cases, the receiving SMTP 164 server or its proxy may have no way to rate a particular direct 165 accreditation service the sending SMTP client uses, and it will be 166 ignored. 168 In order to facilitate resolution of problematic listings, a 169 receiving SMTP server that refuses access to a sending SMTP client, 170 due to an unfavorable recommendation, SHOULD return an error message 171 that cites the accreditation service(s) providing the basis for the 172 rejection. 174 4. Listing Pointer Service Record Template 176 A domain may list services that provide accreditation information 177 about the operations associated with that name. The DNS records they 178 SHOULD list are in the form: 180 1. Name: The domain name that will be checked 182 2. Type: PTR 184 3. Class: IN 186 4. TTL: Standard DNS meaning 188 5. Target: QNAME string (starting with "_VOUCH._SMTP.") for a DNS 189 SRV query to return the preferred access method for 190 human-readable queries to a suggested accreditation service. 192 Concatenating (with a single dot between them) the domain name of a 193 sender recommending this service with this target domain name 194 (without the "_VOUCH._SMTP.") and doing a DNS query for a TXT record 195 SHOULD return a string giving a report on the trustworthiness of the 196 client domain. 198 5. Accreditation Procedure 200 A receiving SMTP server MAY validate a sending SMTP client by: 202 1. Obtaining the domain name of the client. 204 2. Determining that the name is being used by an authorized party. 206 3. Creating a list of accreditation services to query, both those 207 the client has registered and those obtained by the server 208 through other means -- such as those that perform block-listing 209 -- to query. 211 4. Querying those services for assessments of the host associated 212 with that name. 214 5. Synthesize a single assessment using the responses from the 215 multiple services; this is done according to whatever weightings 216 and other methods local policy may dictate. 218 6. Returning the recommendation -- with a value of "unknown" if no 219 records were found or if none of the recommended accreditation 220 services are known. 222 Alternatively, the receiving SMTP server MAY query any trusted 223 accreditation service which itself performs steps 3 through 6 and 224 reports a single recommendation. 226 In the event that the query procedure is unable to produce a useful 227 assessment, the decision on how much trust to place in the client is 228 outside the scope of this document. 230 If the final report is "not recommended", the server SHOULD return an 231 error including the name of an accreditation service that reported 232 Not-Recommended. We suggest using "550 Access Denied based on 233 report." 235 6. Accreditation Report Record Template 237 A direct accreditation service MUST publish its listings using the 238 following record and format: 240 1. Name: .. 242 2. Type: TXT 244 3. Class: IN 246 4. TTL: Standard DNS meaning 248 5. Target: Accreditation Report string. 250 The Accreditation Report string MUST contain a report for a 251 particular service, encoded as: 253 1. service accredited 255 2. comma 257 3. level accredited for (service-specific, may be empty) 259 4. comma 261 5. recommendation, specified as: 263 1. 'A' for Strongly Recommended 265 2. 'B' for Recommended 267 3. 'C' for Unknown 269 4. 'D' for Not Recommended 271 5. 'E' for Strongly Not Recommended 273 6. semicolon (or end-of-string) 275 7. optional info (format is local to each accreditation service). 277 Strings which do not match this format MAY have meaning outside the 278 scope of this specification and MUST be ignored by DNA parsers 279 unaware of such meaning. 281 For MARID-CSV, the "service accredited" MUST be "MARID" and the 282 "level accredited" currently MUST be "1". 284 The "Accreditation Service" string portion of the Query Name above 285 should match the RDATA string of the Suggested Service Record 286 published by the domain being checked, with the "_VOUCH._SMTP." 287 substring removed. 289 7. Discussion of DNS record types 291 For the DNS records listing recommended accreditation services, we 292 have chosen to use the existing PTR record type. It is perfectly 293 suited to our needs, yielding a domain-name as the answer and having 294 no known competing uses at the subdomain levels matching likely EHLO 295 strings. Conflicts with possible future uses are prevented by 296 prefixing the substring "_VOUCH._SMTP." so as to point to a SRV query 297 string. Any CSV queries MUST discard any PTR records returned which 298 do not contain that prefix. 300 For the DNS records giving accreditation reports, we have chosen the 301 existing TXT records. We believe that accreditation services should 302 be given the full flexibility of free-format text in addition to the 303 limited formatted text we specify here. There should be no future 304 conflicts except for accreditation relating to other services, for 305 which we specify that each TXT record should start with the name of 306 the service being accredited. Since all these records are at 307 subdomains generated by concatenating two different domain names, 308 naming conflicts for the query string cannot arise unless the 309 accreditation service chooses subdomain (host) names which overlap 310 top-level domain names. 312 For both record types, wildcards will work. Domain management can 313 specify the same accreditation service(s) for all possible subdomains 314 with wildcard PTR record(s). Accreditation services can specify the 315 same accreditation report for all possible subdomains with a single 316 TXT record. 318 8. Security Considerations 320 This entire proposal pertains to security, namely authorization and 321 verification of clients seeking services. 323 It specifies a way for client domains to advertise the names of 324 accreditation services in DNS. Various well-known attacks on DNS 325 services may result in failure to respond to queries or in the 326 receipt of out-of-date information. However, servers need not use 327 this information directly, and are more likely to use out-of-band 328 methods to query their preferred accreditation service. 330 9. References - Normative 332 [ID-Marid-CSV] 333 Crocker, D., Otis, D. and J. Leslie, "Certified Server 334 Validation (CSV))", July 2004. 336 [RFC1035] Mockapetris, P., "Domain names - implementation and 337 specification", STD 13, RFC 1035, November 1987. 339 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 340 April 2001. 342 Authors' Addresses 344 John Leslie 345 JLC.net 346 10 Souhegan Street 347 Milford, NH 03055 348 USA 350 Phone: +1.603.673.6132 351 Email: john@jlc.net 352 Dave Crocker 353 Brandenburg InternetWorking 354 675 Spruce Drive 355 Sunnyvale, CA 94086 356 USA 358 Phone: +1.408.246.8253 359 Email: dcrocker@brandenburg.com 361 Douglas Otis 362 Mail Abuse Prevention System 363 1737 North First Street, Suite 680 364 San Jose, CA 94043 365 USA 367 Phone: +1.408.453.6277 368 Email: dotis@mail-abuse.org 370 Intellectual Property Statement 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at 392 ietf-ipr@ietf.org. 394 Disclaimer of Validity 396 This document and the information contained herein are provided on an 397 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 398 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 399 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 400 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 401 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 402 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 404 Copyright Statement 406 Copyright (C) The Internet Society (2005). This document is subject 407 to the rights, licenses and restrictions contained in BCP 78, and 408 except as set forth therein, the authors retain all their rights. 410 Acknowledgment 412 Funding for the RFC Editor function is currently provided by the 413 Internet Society.