idnits 2.17.1 draft-moonesamy-smtp-vrfy-ddds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 193 has weird spacing: '... order pref...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Moonesamy 3 Internet Draft May 25, 2009 4 Intended status: Standards Track 5 Expires: November 24, 2009 7 SMTP Recipient Address Verification Using the Dynamic 8 Delegation Discovery Service (DDDS) 9 draft-moonesamy-smtp-vrfy-ddds-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 24, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 This document may contain material from IETF Documents or IETF 46 Contributions published or made publicly available before 47 November 10, 2008. The person(s) controlling the copyright in 48 some of this material may not have granted the IETF Trust the 49 right to allow modifications of such material outside the 50 IETF Standards Process. Without obtaining an adequate license 51 from the person(s) controlling the copyright in such materials, 52 this document may not be modified outside the IETF Standards 53 Process, and derivative works of it may not be created outside 54 the IETF Standards Process, except to format it for publication 55 as an RFC or to translate it into languages other than English. 57 Abstract 59 This memo proposes a mechanism based on the Dynamic Delegation 60 Discovery Service (DDDS) which can be used for the verification 61 of SMTP recipient addresses. 63 1. Introduction 65 SMTP servers for a domain identified through higher numbered MX 66 records are sometimes specifically targetted for mail delivery as 67 they do not enforce the same policies for the domain. This can 68 generate backscatter where the message is accepted by a SMTP server 69 and bounced because the SMTP recipient address was rejected by a 70 SMTP server further down in the delivery path, generally identified 71 by a lower numbered MX record, to a mailbox that did not elect to 72 receive the non-delivery notification message. 74 SMTP provides a VRFY command [RFC5321] to verify a user name. This 75 command is generally disabled in SMTP server implementations for 76 security reasons. Some SMTP clients get around that by doing a 77 partial mail transaction without proceeding to the third step 78 (DATA command). This document proposes a mechanism based on the 79 Dynamic Delegation Discovery Service (DDDS) [RFC3401][RFC3402] 80 [RFC3403][RFC3404] where the local-part of a RFC 5321 [RFC5321] 81 address is associated with a Naming Authority Pointer (NAPTR) DNS 82 Record Resource [RFC3403]. This mechanism can be used for the 83 verification of SMTP recipient addresses. 85 Subaddressing is the practice of augmenting the local-part of an 86 RFC 5321 address with some "detail" information in order to give 87 some extra meaning to that address. One common way of encoding 88 "detail" information into the local-part is to add a "separator 89 character sequence", such as "+", to form a boundary between the 90 "user" (original local-part) and "detail" sub-parts of the address, 91 much like the "@" character forms the boundary between the local-part 92 and domain. The NAPTR Record Resource was chosen as it is a Record 93 Resource (RR) that includes a a regular expression. That can be used 94 to support subaddressing. 96 1.1. Comments 98 Comments and discussions about this draft can be directed to the 99 SMTP mailing list, ietf-smtp, maintained at imc.org. 100 [RFC Editor: Please remove this subsection] 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. VRFY Application 110 The VRFY Application uses the NAPTR RR to map the local-part 111 of a RFC 5321 address to a regular expression. SMTP servers 112 can use the regular expression to verify local-part and "detail" 113 of a RFC 5321 address. 115 The maximum total length of a user name or other local-part, as 116 defined in RFC 5321, is 64 octets. It is important to note that 117 domain labels are limited to 63 characters in length and the 118 total length of the resulting string must be 255 octets or 119 less [RFC1035]. For the purposes of this specification, the 120 local-part of a RFC 5321 address for the VRFY Application 121 MUST be not be more than the limit defined for a domain label in 122 [RFC1035]. 124 3.1. Application Usage String 126 The application unique string is a RFC 5321 address limited to 63 127 characters. 129 3.2. First Well Known Rule 131 The first known key is the local-part of the RFC 5321 address. For 132 example, postmaster@example.com would have "postmaster" as its first 133 key. 135 3.3 Expected Output 137 The output of the First Well Known Rule for the VRFY Application 138 is a regular expression. The "regexp" field is defined in [RFC3402] 139 as consisting of a "delim-character", a POSIX Extended Regular 140 Expression, a "delim-character" and a final "delim-character". 141 The regular expression MUST match a valid local-part as defined for a 142 RFC 5321 address. For this application the following rules apply: 144 The "delim-character" MAY be any valid character as defined in 145 section 3.2 of [RFC3402]. 147 The regular expression MUST NOT contain a substitution expression. 149 The "replacement" field MUST be empty. 151 3.4. Valid Databases 153 A DDDS Database is specified for this Application. The Keys for 154 this database are encoded as domain names. The characters allowed 155 to be in a Key are those that are currently defined for DNS domain 156 names. 158 The string "._vrfy._smtp._tcp." is appended to the output 159 of the First Well Known Rule. The domain name part of the RFC 5321 160 address is then appended to the end. 162 3.5. Flags 164 The "flags" field MUST contain the character "U". 166 The "order" and "preference" fields are to be processed as 167 specified in [RFC3403]. If multiple records are returned, the 168 one(s) with the lowest "order" value that have a matching 169 "service" field MUST be used. Of those with the lowest order 170 value, those with the lowest "preference" SHOULD be used. 172 3.6. Service Parameters 174 The "services" field MUST only contain the string "SMTP+VRFY". 176 4. Example 178 $ORIGIN example.com. 179 user._vrfy._smtp._tcp IN NAPTR 10 1 ( ; order pref 180 "u" "SMTP+VRFY" ; flags service 181 "!^(user)$!!" . ; regexp replacement 182 ) 184 The result of the extraction of the local-part of the RFC 5321 185 address, user@example.com, is "user". The "separator character 186 sequence" and "detail" are removed from the extracted string if 187 subaddressing is used. The "user" (original local part) becomes 188 the Application Usage String. The NAPTR RR to lookup is 189 "user._vrfy._smtp._tcp.example.com.". The record returned is in 190 the form: 192 user._vrfy._smtp._tcp.example.com. IN NAPTR 193 ;; order pref flags service regexp replacement 194 10 1 "u" "SMTP+VRFY" "!^(user)$!!" . 196 The regular expression in the record is "!^(user)$!!". The "!" 197 character is used to delimit the parts of the substitution 198 expression. The replacement field is empty. There is a match when 199 the regular expression is applied to the local-part and "detail" of 200 the RFC 5321 address being verified. 202 5. Security Considerations 204 The SMTP VRFY command [RFC5321] is generally disabled in SMTP 205 servers due to security considerations. It is recommended to 206 use transaction level authentication such as Secret Key 207 Transaction Authentication for DNS (TSIG) [RFC2845] or access 208 control mechanisms to restrict access to the DDDS database. Domain 209 Name System Security Extensions (DNSSEC) [RFC4033] can be used to add 210 data origin authentication and data integrity. 212 The amount of DNS queries generated by implementations can be 213 substantial. Without the appropriate DNS infrastructure, that 214 can cause a denial of service. 216 Regular expressions should be checked for sanity, not blindly 217 passed. 219 6. Internationalization Considerations 221 Non-ASCII characters in domain names are encoded using the 222 Internationalizing Domain Names in Applications specification 223 [RFC3490]. 225 7. IANA Considerations 227 The IANA maintains an Application Service Tag Registry for the 228 S-NAPTR DDDS application defined in [RFC3958]. The IANA is advised 229 that although the application defined in this document is not a 230 S-NAPTR DDDS application, it defines a "SMTP+VRFY" value for the 231 "services" field. That value should not be used in the Application 232 Service Tag Registry for other applications. 234 8. Acknowledgements 236 The idea of using DNS for recipient address verification originated 237 from David Skoll during a discussion about SMTP in May 2007. 239 9. References 241 9.1. Normative References 243 [RFC1035] Mockapetris, P., "Domain names - implementation and 244 specification", STD 13, RFC 1035, November 1987. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 250 Part Two: The Algorithm", RFC 3402, October 2002. 252 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 253 Part Three: The Doman Name System (DNS) Database", 254 RFC 3403, October 2002. 256 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 257 Part Four: The Uniform Resource Identifiers (URI) 258 Resolution Application", RFC 3404, October 2002. 260 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", 261 RFC 5321, October 2008. 263 9.2. Informative References 265 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and 266 B. Wellington, "Secret Key Transaction Authentication for 267 DNS (TSIG)", RFC 2845, May 2000. 269 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 270 Part One: The Algorithm", RFC 3401, October 2002. 272 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 273 "Internationalizing Domain Names in Applications (IDNA)", 274 RFC 3490, March 2003. 276 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 277 Service Location Using SRV RRs and the Dynamic Delegation 278 Discovery Service (DDDS)", RFC 3958, January 2005. 280 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and 281 S. Rose, "DNS Security Introduction and Requirements", 282 RFC 4033, March 2005. 284 Author's Address 286 S. Moonesamy 287 76, Ylang Ylang Avenue 288 Quatre Bornes 289 Mauritius 291 Email: sm+ietf@elandsys.com