I have been selected as the Applications Area Review Team reviewer for this draft. For background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team
 
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
 
Document: draft-ietf-appsawg-rrvs-header-field-05
Title: The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
Reviewer: Eric Burger
Review Date: 23-December-2013
 
Summary: Short of a toxic waste warning indicating that this mechanism does not provide a guarantee of delivery to the intended addressee, this document is pretty much ready for publication.
 
 
MAJOR ISSUES
While this mechanism is not as bad as the ill-fated recall message mechanism, it shares the same characteristic. Namely, this extension is at best a request. What makes is not as bad as recall message is the use case is for big, industrial message senders sending messages to big, industrial messaging service providers (MSPs). In this scenario, the sender presumably fully understands this mechanism will not relieve them of SOX or HIPPA or other regulatory requirement not to inadvertently release information. Likewise, the MSP is advertising (out of band) to these large enterprises that they will do their best to honor the RRVS mechanism.

The problem is like anything in the Internet, this mechanism will leak out from this particular use case. Specifically, someone will invariably expose the mechanism to a MUA UI. Therefore, I would insert the following language in the document. My proposal would be at the end of Section 4, to the effect of:
   The initial use for the mechanism described in this document is for machine-generated
   messages, such as from a bank to a user. This specification presumes an enterprise
   application developer understands the limitations of the mechanism. For an interactive
   mail application used by casual users, if the user requests the use of the mechanism
   described in this document, we RECOMMEND the application displays a dialog box or
   other appropriate indicator, in the user's language, stating the RRVS request is a
   suggestion only and the message is likely to be delivered, without warning or notice
   to the sender.
 
Along the lines of the above, we could use a mechanism such as RFC3459. If you are a MUA and your SUBMIT server does not support RRVS, fail. If you are a SUBMIT server or MTA and the next hop does not support RRVS, fail.
 
There is no way to prevent a bad actor from commandeering a domain for the purposes of snagging personal information from unsuspecting users. Because of this, I would insist that the Security section point out that this mechanism does not provide any security against a sender inadvertently releasing personal information to a stale address. One known mechanism to ensure the right user receives the information is to encrypt the message in such a manner that only the right user can decrypt the message. See S/MIME (RFC5751) or PGP (RFC4880) for examples of how to ensure only the right user* can read the message.  [* Admittedly, this only says that an entity with a decryption key can read the message, but that is infinitely more security than what RRVS offers.]
 
p. 17, Section 15.3: How would an MTA know the message was forwarded and not originated? Is this not a UA thing?
 
I would offer Ned's issues raised on 13 December 2013 at 9:50am PT should all be addressed. I have no opinion on the DKIM signature issues, other than that if we have a header that pops in and out of existence, it makes no sense to attempt to calculate a signature over it (except for hop-by-hop).



MINOR ISSUES
p. 8, step 7: "being forwarded" is ambiguous. Is this a user forwarding amessage in a MUA UI or is this a mail server forwarding a message to a more appropriate address?
 
p. 8, Section 6: Does this say something? If it does, it is not clear what it is saying. A "user handling those mailboxes" would know if ownership changed, because they are a "user *handling*" the mailbox. If it is about a sender learning that ownership changed, then this is a no-op because the MTA/MUA are not supposed to do RRVS processing on role mailboxes.
 
p. 8, Section 7: as others have noted, there needs to be a forward reference to Section 10 here, or move Section 10 earlier in the document.
 
p. 9, Section 7.1: There is a complement to the spam processing discussed in Section 14.2. Specifically, if a malevolent actor is monitoring mail traffic, a RRVS header might be an indicator the message will be of interest or high value.
 
p. 10ff, Section 9.2: Would it not be better to just say this whole think is a "matter of local policy"? The goal is to make sure it makes sense to deliver, or reject, a message in the case of a change of ownership of the mailbox. These steps are all situation-dependent and not really of general value. Same for Section 9.4.



NITS
Others have found them, so no need to reiterate them here.