idnits 2.17.1 draft-hathcock-minger-06.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 122 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 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 IETF Trust and authors 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 3, 2009) is 5377 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5034' is mentioned on line 160, but not defined == Unused Reference: 'RFC1734' is defined on line 272, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1734 (Obsoleted by RFC 5034) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Hathcock 2 Internet-Draft J. Merkel 3 Intended Status: Informational Alt-N Technologies 4 Expires: February 3, 2010 August 3, 2009 6 The Minger Email Address Verification Protocol 7 draft-hathcock-minger-06.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on February 3, 2010. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 38 Relating to IETF Documents in effect on the date of publication of 39 this document (http://trustee.ietf.org/license-info). Please 40 review these documents carefully, as they describe your rights and 41 restrictions with respect to this document. 43 Abstract 45 This document describes the Minger protocol. Minger is a protocol 46 which allows a mail handling entity to query a remote service and 47 ask the question "do you accept mail for this email address?" It 48 includes security in the form of a hashed shared secret but can also 49 be used anonymously if desired. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. The problem . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Existing solutions . . . . . . . . . . . . . . . . . . . 3 62 1.3. The Minger solution . . . . . . . . . . . . . . . . . . 4 63 2. The Minger protocol . . . . . . . . . . . . . . . . . . . . 4 64 2.1 The Minger query process . . . . . . . . . . . . . . . . 4 65 2.2 Description of query elements . . . . . . . . . . . . . . 5 66 3. Minger responses . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1 Description of response elements . . . . . . . . . . . . 5 68 3.2 Example responses . . . . . . . . . . . . . . . . . . . . 6 69 4. Anonymous mode . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 72 7. Informative References . . . . . . . . . . . . . . . . . . . 7 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 Intellectual Property and Copyright Statements . . . . . . . . . 9 77 1. Introduction 79 1.1 The problem 81 It is common for elements within a typical email handling topology 82 to be unaware of whether individual local-parts are valid for the 83 mail it accepts. For example, so-called "edge" servers which provide 84 security oriented services for downstream mail handling elements 85 often do not have an exhaustive listing of all valid local-parts for 86 a given domain. Thus, they are sometimes forced to accept and process 87 messages which might otherwise be rejected as "user unknown". 88 Similarly, entities offering "backup MX" mail services are rarely 89 privy to a complete local-part listing and are therefore often decide 90 to accept messages which might otherwise be rejected. Finally, even 91 within a common administrative framework of several locally maintained 92 and controlled SMTP servers in a load balanced configuration, it is 93 not always possible for all servers to access a common local-part 94 database. 96 1.2 Existing solutions 98 The need to determine whether an email address contains a valid local 99 part has lead to the use of at least two existing mechanisms - Finger 100 [RFC1288] and SMTP "call-forward". 102 Finger [RFC1288] describes a protocol for the exchange of user 103 information. In theory, Finger could be used to determine whether an 104 account exists by careful examination of the results of a Finger 105 query. However, Finger suffers from a lack of security which makes 106 its modern day use problematic when coupled with the user level 107 detail it can provide. Also, Finger requires the use of TCP rather 108 than UDP which seems ill suited to a simple verification scheme. 110 SMTP "call-forward" is a term used to describe a widespread practice 111 whereby SMTP servers place an incoming SMTP session on hold while they 112 attempt to use an outbound SMTP session to determine whether or not a 113 given email address is valid. The theory behind this is as follows: 114 if an SMTP server responds positively to an SMTP RCPT command 115 [RFC2821] with a given email address then this potentially means that 116 the address local-part is valid. One problem with such a scheme is 117 the lack of efficiency inherent in the need to tear-up and tear-down 118 an SMTP session over TCP. Also, because these types of SMTP sessions 119 are not purposed to deliver mail, they typically drop connection after 120 the RCPT command is processed. This leads to a large number of SMTP 121 sessions which appear in logs to have simply failed for no reason. 122 This leads to situations in which SMTP transaction logs can no longer 123 distinguish legitimate network errors from "call-forward" traffic. 125 SMTP includes a VRFY command which can be used to determine whether 126 an email address exists. VRFY is not in wide-spread use and suffers 127 from the same inefficiency concerns described in the discussion on 128 SMTP "call-forward". Additionally, SMTP agents providing mail 129 services to a domain are often not authoritative making VRFY requests 130 potentially unreliable. 132 LDAP could be used to determine whether an email address exists. 133 However, LDAP is overly complex to configure and maintain. 135 1.3 The Minger solution 137 What's needed is a protocol which is secure, has little overhead, and 138 can be easily invoked to determine whether a given email address is 139 valid or not. Minger achieves these goals using a shared secret for 140 security and UDP to lower overhead. 142 2. The Minger protocol 144 Minger is a UDP protocol that operates on port 4069. 146 Syntax descriptions use the form described in Augmented Backus-Naur 147 Form for Syntax Specifications (ABNF) [RFC4234]. 149 2.1 The Minger query process 151 A Minger client constructs a query string as described below and 152 transmits it over UDP to a Minger server. The format of the query 153 is as follows: 155 ABNF: 157 query-string = mailbox [SP %x64 "=" digest] [SP tag-list] 159 digest = base64 ; digest for security 160 ; base64 defined in [RFC5034] 162 digest-text = shared-secret ":" mailbox ; input text for digest 164 mailbox = Local-part "@" Domain ; as defined in [RFC2821] 166 shared-secret = 1*50(VCHAR) ; password credential 167 tag-list = tag-spec *(SP tag-spec) ; tag/value list 169 tag-spec = tag-name "=" tag-value 171 tag-name = 1 * ( ALPHA / DIGIT / "_") ; except 'd' 173 tag-value = 1 * (ALPHA / DIGIT / "_") 175 2.2 Description of query elements 177 mailbox 179 This is the email address for which verification of 180 existence is desired. 182 digest 184 This is the base64 encoding of the MD5 [RFC1321] hash of 185 digest-text. Digest-text is constructed, the MD5 hash of that 186 is computed, and that result is base64 encoded. 188 tag-list 190 Tag-list is provided so that future capability might be added 191 in an easy way. Tag-names are case-sensitive and MUST NOT 192 be used more than once. 194 3. Minger responses 196 Minger servers return a response string of the following form: 198 ABNF: 200 response-string = mailbox status 202 mailbox = Local-part "@" Domain ; as defined in [RFC2821] 204 status = %x30-35 ; single digit result code 205 ; from 0 - 5 207 3.1 Description of response elements 209 mailbox 211 This is the email address for which verification of 212 existence is desired. 214 status 216 The following status codes are defined: 218 0 - invalid request (for example, malformed query string) 219 1 - access denied (for example, query from unauthorized IP) 220 2 - bad or missing credentials (returned when anonymous 221 mode is disabled and no credentials were provided in the 222 query string or when the credentials themselves are 223 invalid) 224 3 - email address does not exist 225 4 - email address exists but can not receive mail (for example, 226 the account associated with the email address has exceeded 227 local storage constraints or it is otherwise disabled due 228 to local policy) 229 5 - email address exists and is active (able to receive mail) 231 3.2 Example responses 233 Minger response returned when the queried email address does 234 not exist: 236 arvel@example.com 3 238 Minger response returned for invalid credentials: 240 arvel@example.com 2 242 Minger response returned when the queried email address exists: 244 arvel@example.com 5 246 4. Anonymous mode 248 Minger clients MAY attempt anonymous queries; that is, queries which 249 do not contain a shared secret digest within the query string. Minger 250 servers MAY be configured to refuse anonymous queries. If so, they 251 MUST respond with a status of "2". 253 5. Security Considerations 255 Minger is a protocol which is used to determine whether a given 256 email address is valid or not. If a particular email 257 infrastructure does not wish to advertise the email addresses that 258 it services then this protocol should not be employed. 260 If a shared secret is employed to secure Minger from anonymous use 261 that shared secret should be at least 128 bits. 263 6. IANA Considerations 265 IANA has assigned tcp & upd port 4069 for Minger. 267 7. Informative References 269 [RFC1288] Zimmerman, D., "The Finger User Information Protocol", 270 RFC 1288, December 1991. 272 [RFC1734] Myers, J., "POP3 Authentication Command", RFC 1734, 273 December 1994. 275 [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 276 2821, March 2001. 278 [RFC4234] Crocker, D., Ed. And P. Overell, "Augmented BNF for Syntax 279 Specifications: ABNF", RFC 4234, October 2005. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC1321] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 285 MIT Laboratory for Computer Science and RSA Data Security, 286 Inc., April 1992. 288 Appendix A. Acknowledgements 290 We wish to thank the members of the MDaemon Beta Community 291 for their ideas and help and Paul Hoffman for his valuable feedback. 293 Authors' Addresses 295 Arvel Hathcock 296 Alt-N Technologies 297 http://www.altn.com 299 Email: arvel.hathcock@altn.com 301 Jonathan Merkel 302 Alt-N Technologies 303 http://www.altn.com 305 Email: jon.merkel@altn.com 307 Acknowledgment 309 Funding for the RFC Editor function is provided by the IETF 310 Administrative Support Activity (IASA).