I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Summary: Ready with nits This draft describes both an SMTP extension and a mail header field that enable validation that an email address is still valid for the intended recipient. The draft is well-written and clear. -- Nits: a) Section 5.2 Header Field Used 4. RECOMMENDED: If local delivery is being performed, remove all instances of this field prior to delivery to a mailbox; if the message is being forwarded, remove those instances of this header field that were not discarded by steps 1-4 above. Well, only step 2 can discard instances, so "steps 1-4" -> "step 2". b) Section 9.2 Single-Recipient Aliases Upon delivery of an RRVS-protected message to an alias (acting in place of a mailbox) that results in relaying of the message to a single other destination, the usual RRVS check is performed. The continuous ownership test here might succeed if a conventional user inbox was replaced with an alias on behalf of that same user, and this information is recorded someplace. If the message is thus accepted, the relaying MTA can choose to do one of the following: 1. Do not include an RRVS parameter or header field when relaying to the new address. (RECOMMENDED) This exposes the message to relaying via an alias at the new address to an unintended recipient. That should be noted, although this double-relaying feels like a case where the original user ought to be responsible for ensuring that the first alias is updated when the second alias is installed so that relaying occurs only once (which is probably also worth noting). Options 2 and 3 eliminate this exposure, but note the additional operational complexity of doing so, and Section 5.2.1 indicates that a single alias-based relay is the design center for this draft. -- Operational Review Q&A (selected questions) A.1.1. Has deployment been discussed? Yes, this is an extension to the existing SMTP protocol that would be added to existing implementations; deployment is straightforward. A.1.3. Has the migration path been discussed? Yes, there is good discussion of what happens when a downstream MTA does not support the SMTP extension or header field. The header field is noted as transparent to implementations that do not support it, thereby providing functionality that can cross MTAs that lack support. A.1.6. Have suggestions for verifying correct operation been discussed? No, Section 7 describes relaying scenarios in which the protection provided by this protocol can be removed. While doing so is NOT RECOMMENDED for MTA implementations, there is no obvious way for a sender or originating MTA to figure out what the scope of protection is when relaying occurs. A.2 Do you anticipate any manageability issues with the specification? Not directly. This functionality requires that receiving MTAs keep time-based records of address ownership, which has implications for management of such MTAs, but such MTA management implications are well beyond the scope of this draft. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------