Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA15634; Thu, 20 Aug 1998 11:37:09 -0400 (EDT) Received: by cs.cs.utk.edu (bulk_mailer v1.11); Thu, 20 Aug 1998 11:36:46 -0400 Received: by CS.UTK.EDU (cf v2.9s-UTK) id LAA15570; Thu, 20 Aug 1998 11:36:45 -0400 (EDT) Received: from HQ.Cisco.COM (hq.cisco.com [171.71.68.70]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id LAA15558; Thu, 20 Aug 1998 11:36:39 -0400 (EDT) Received: by HQ.Cisco.COM for DRUMS@cs.UTK.EDU; Thu, 20 Aug 1998 8:36:10 -0700 Date: Thu, 20 Aug 1998 8:36:10 -0700 From: Dan Wing To: DRUMS@cs.utk.edu Message-Id: <980820083610.20902294@Cisco.COM> Subject: VRFY wording for draft-ietf-drums-smtpupd-08.txt List-Unsubscribe: Attached is my recommended wording which, I believe, combines the wording of Dan Wing, Keith, and Norbert, and the recent comments on the mailing list. To avoid repeating everything in the security section, with possibly two interpretations, I just pointed the reader to the Implementation Requirements section (3.5.3) which describes the security implications of allowing 'true' VRFY support. -Dan Wing ----- *** draft-ietf-drums-smtpupd-08.txt Thu Aug 20 08:02:16 1998 --- drums.txt Thu Aug 20 08:28:59 1998 *************** *** 74,81 **** 3.4 Forwarding for Address Correction or Updating 3.5 Commands for Debugging Addresses 3.5.1 Overview ! 3.5.2 VRFY Normal Response ! 3.5.3 Meaning of VRFY or EXPN Success Response 3.5.4 Semantics and Applications of EXPN 3.6 Domains 3.7 Relaying --- 74,81 ---- 3.4 Forwarding for Address Correction or Updating 3.5 Commands for Debugging Addresses 3.5.1 Overview ! 3.5.2 VRFY and EXPN Normal Response ! 3.5.3 VRFY Implementation Requirements 3.5.4 Semantics and Applications of EXPN 3.6 Domains 3.7 Relaying *************** *** 825,832 **** SMTP provides commands to verify a user name or obtain the content of a mailing list. This is done with the VRFY and EXPN commands, which have ! character string arguments. Implementations MUST support VRFY and SHOULD ! support EXPN (however, see section 3.5.2 and 7.3). For the VRFY command, the string is a user name or a user name and domain (see below). If a normal (i.e., 250) response is returned, the response MAY --- 825,831 ---- SMTP provides commands to verify a user name or obtain the content of a mailing list. This is done with the VRFY and EXPN commands, which have ! character string arguments. For the VRFY command, the string is a user name or a user name and domain (see below). If a normal (i.e., 250) response is returned, the response MAY *************** *** 853,860 **** or 553-Ambiguous; Possibilities ! 553- ! 553- 553 Under normal circumstances, a client receiving a 553 reply would be --- 852,859 ---- or 553-Ambiguous; Possibilities ! 553- ! 553- 553 Under normal circumstances, a client receiving a 553 reply would be *************** *** 887,899 **** mailbox is to be specified on each line of the reply. The case of an ambiguous request is discussed above. ! "User name" is a fuzzy term and has been used deliberately. An ! implementation of the VRFY or EXPN commands MUST include at least ! recognition of local mailboxes as "user names". However, since current ! Internet practice often results in a single host handling mail for multiple ! domains, hosts, especially hosts that provide this functionality, SHOULD ! accept the "local-part@domain" form as a "user name"; hosts MAY also choose ! to recognize other strings as "user names". The case of expanding a mailbox list requires a multiline reply, such as: --- 886,896 ---- mailbox is to be specified on each line of the reply. The case of an ambiguous request is discussed above. ! "User name" is a fuzzy term and has been used deliberately. Since ! current Internet practice often results in a single host handling mail ! for multiple domains, hosts, especially hosts that provide this ! functionality, SHOULD accept the "local-part@domain" form as a "user ! name"; hosts MAY also choose to recognize other strings as "user names". The case of expanding a mailbox list requires a multiline reply, such as: *************** *** 904,910 **** or ! C EXPN Executive-Washroom-List S: 550 Access Denied to You. The character string arguments of the VRFY and EXPN commands cannot be --- 901,907 ---- or ! C: EXPN Executive-Washroom-List S: 550 Access Denied to You. The character string arguments of the VRFY and EXPN commands cannot be *************** *** 917,923 **** carefully, if at all, and SHOULD generally only be used for diagnostic purposes. ! 3.5.2 VRFY Normal Response When normal (2yz or 551) responses are returned from a VRFY or EXPN request, the reply MUST normally include the mailbox name. --- 914,920 ---- carefully, if at all, and SHOULD generally only be used for diagnostic purposes. ! 3.5.2 VRFY and EXPN Normal Response When normal (2yz or 551) responses are returned from a VRFY or EXPN request, the reply MUST normally include the mailbox name. *************** *** 931,965 **** other system, the mailbox name used to reach that target MUST be given. Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN. ! Server implementations MUST support VRFY and SHOULD support EXPN. For ! security reasons, implementations MAY provide local installations a way to ! disable either or both of these commands through configuration options or ! the equivalent. When these commands are supported, they are not required ! to work across relays when relaying is supported. Since they were both ! optional in RFC 821, they MUST be listed as service extensions in an EHLO ! response, if they are supported. ! ! 3.5.3 Meaning of VRFY or EXPN Success Response ! ! A server MUST NOT return a 220 code in response to a VRFY or EXPN command ! unless it has actually verified the address. In particular, a server MUST ! NOT return 220 if all it has done is to verify that the syntax given is ! valid. In that case, 502 (Command not implemented) or 500 (Syntax error, ! command unrecognized) SHOULD be returned. As stated elsewhere, ! implementation of VRFY is required and EXPN is strongly recommended. ! Hence, implementations that return 500 or 502 for VRFY are not in ! compliance with this specification. ! ! There may be circumstances where an address appears to be valid but cannot ! reasonably be verified in real time, particularly when a server is acting ! as a mail exchanger for another server or domain. "Apparent validity" in ! this case would normally involve at least syntax checking and might involve ! verification that any domains specified were ones to which the host ! expected to be able to relay mail. In these situations, reply code 252 ! SHOULD BE returned. These cases parallel the discussion of RCPT ! verification discussed in section 2.1 Implementations generally SHOULD be ! more aggressive about address verification in the case of VRFY than in the ! case of RCPT, even if it takes a little longer to do so. 3.5.4 Semantics and Applications of EXPN --- 928,987 ---- other system, the mailbox name used to reach that target MUST be given. Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN. ! Neither VRFY or EXPN are required to work across relays when relaying is ! supported. <> ! ! 3.5.3 VRFY Implementation Requirements ! ! Some SMTP clients use the VRFY verb to validate deliverable addresses. ! Even though such use is inconsistent with RFC 821, support for the VRFY ! command was required by RFC 1123. ! ! Because of this behavior, the VRFY command MUST NOT return a 5xy ! response code unless the recipient address is actually known to be ! invalid. In other cases, one of the following response codes SHOULD be ! returned. Note that is required syntax. ! ! 250 Valid local mailbox ! (If the recipient address is known to be a valid local address. ! This SMTP response does not guarantee that RCPT commands for ! this address must always succeed.) ! ! 251 mail will be forwarded to ! (for a local recipient with mail forwarding) ! ! This response includes the address to which the mail is ! forwarded. If the specific forwarding address cannot be ! disclosed code 252 SHOULD be returned. ! ! 252 Cannot VRFY ! (If server cannot determine if mailbox is valid, or refuses ! to disclose the information, or the SMTP server implementation ! doesn't include code to determine if a mailbox is valid) ! ! Note that the meaning of 252 has changed slightly from RFC 1123; ! a response of 252 to VRFY is NOT an assurance that the ! SMTP server will accept a message for that recipient. ! ! The text in the 250 or 252 response MAY contain additional information, ! such as the recipient's personal name, but SMTP servers SHOULD be ! configurable to not disclose such information. Also, SMTP servers ! SHOULD be configurable to avoid using the 251 response which discloses ! forwarding addresses. ! ! Implementors are encouraged to make reasonable efforts to support the ! full functionality of the VRFY command, as this can aid remote mail ! administrators in diagnosing mail loops and similar problems. ! ! However, VRFY can also disclose sensitive information (such as users' ! personal names, forwarding addresses, or even whether an address is ! valid) to unauthorized parties. SMTP servers SHOULD therefore be ! configureable to not disclose such information, or to disallow ! disclosure of such information on a per-recipient basis. ! ! An SMTP server MAY return 252 in response to all VRFY commands. 3.5.4 Semantics and Applications of EXPN *************** *** 1862,1869 **** 250 Requested mail action okay, completed 251 User not local; will forward to (See section 3.4) ! 252 Cannot VRFY user, but will accept message and attempt ! delivery (See section 3.5.3) 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) --- 1884,1890 ---- 250 Requested mail action okay, completed 251 User not local; will forward to (See section 3.4) ! 252 Cannot VRFY user (See section 3.5.3) 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) *************** *** 1894,1901 **** 250 Requested mail action okay, completed 251 User not local; will forward to (See section 3.4) ! 252 Cannot VRFY user, but will accept message and attempt ! delivery (See section 3.5.3) 354 Start mail input; end with . --- 1915,1921 ---- 250 Requested mail action okay, completed 251 User not local; will forward to (See section 3.4) ! 252 Cannot VRFY user (See section 3.5.3) 354 Start mail input; end with . *************** *** 2252,2260 **** In order to make SMTP workable, the following minimum implementation is required for all receivers. The following commands MUST be supported to conform to this specification: EHLO HELO ! VRFY MAIL RCPT DATA --- 2272,2281 ---- In order to make SMTP workable, the following minimum implementation is required for all receivers. The following commands MUST be supported to conform to this specification: + EHLO HELO ! VRFY (see section 3.5.3) MAIL RCPT DATA *************** *** 2776,2792 **** 7.3 VRFY, EXPN, and Security ! As discussed in section 3.5, individual sites may want to disable one or ! both VRFY or EXPN for security reasons. As a corollary to the above, ! implementations that permit this MUST NOT appear to have verified addresses ! that are not, in fact, verified. If a site disables these commands for ! security reasons, the SMTP server MUST return a 252 response, rather than a ! code that could be confused with successful or unsuccessful verification. ! ! Returning a 250 reply code with the address listed in the VRFY command ! after having checked it only for syntax violates this rule. Of course, an ! implementation that "supports" VRFY by always returning 550 whether or not ! the address is valid is equally not in conformance. Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use --- 2797,2803 ---- 7.3 VRFY, EXPN, and Security ! See the discussion in section 3.5.3 regarding VRFY. Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use *************** *** 3216,3221 **** --- 3227,3233 ---- S: 250-8BITMIME S: 250-SIZE S: 250-DSN + S: 250-VRFY S: 250 HELP C: VRFY Crispin S: 250 Mark Crispin