The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
draft-ietf-appsawg-rrvs-header-field-11

I have no objection to the publication of this document, but here are some pseudo-random thoughts...

---

Section 6 appears to contradict the requirement to ignore or discard
the RRVS stuff in a message that gores to a Role account.

---

Section 8 gives a good warning, but shouldn't it change the
recommendation i bullet two of Section 7?

---

Per Section 15.1 I guess I can use this extension to find out when
someone took over an address (although you do stop me from finding out
when a single-owner address was created). I am not sure that this is a
substantial privacy issue, but maybe the owner of a mailbox should be 
allowed to configure to never support this feature so that all mail
with RRVS will get 550 regardless of when ownership was changed. It 
then becomes the sender's choice whether to have the mail delivered or
not.

I see that Sec 5.2.1 gives an example of usage with forwarding - but doesn't address whether mailbox "B" might have also been subject to reassignment.   Is there a reason that transitivity doesn't apply when a receiver verifies the RRVS and then needs to forward the message.  Logically, shouldn't there be a SHOULD (or at least RECOMMENDED) to apply the same RRVS procedure for the forwarded message?  Presumably, the forwarding system can know when the forwarding was set up and use that as the last-known valid timestamp.
This isn't my field, but transitivity of the protection provided by RRVS seems very important to really solve the problem.


Very Minor Nit:

In Sec 5.2, it says "   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."

Since this is in step 4, it probably should be step 1-3.  


Sec 8:  "Numerous issues arise when using the header field form of this
   extension, particularly when multiple recipients are specified for a
   single message resulting in one multiple fields each with a distinct
   address and timestamp."

I can't parse the last part of this sentence.  Do you mean
"... resulting in multiple fields, where there is one for each recipient and
each such has a distinct address and timestamp." or something similar?

Thanks for resolving my question on section 9.2.

Section 8:

s/resulting in one multiple fields each with a distinct address/resulting in multiple fields each with a distinct address/

Section 9.2:

"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."
   
"Someplace" seems vague. Why isn't this "recorded by the relay"?

I should be missing something.

So a mail sending client is supposed to send "The last time the intended recipient was known to be using this address was this point in time."

How can a mail sending client figure out that the destination of the message has been under continuous ownership for a period of time X?
Is this because I didn't receive any error from a previous email? Not really.
Is this because I received an ACK in the past? I guess no, it's not a guarantee
Is this because I received a reply to my own email? But then, it depends on the content.
	Is this a vacation reply, or some meaningful text like "yes, I agree"

This only text I see on this topic is (section 10):

    Presumably there has been some confirmation process
    applied to establish this ownership of the receiver's mailbox;
    however, the method of making such determinations is a local matter
    and outside the scope of this document.

Without this, I feel this spec is incomplete.
It seems to me that you define the mechanics, but that you don't specify how to use them.
What do I miss?

No record for now.

=====================================

As discussed with Bill:
> We don't specify a way for the sender to know the acount ownership date, but the most common example is the e-mail validation flows common in many sites where the users has to confirm ownership by clicking a link in a piece of e-mail sent to them.

Ah, I completely missed that in the draft. Or maybe I overlooked that?
A few sentences on that context would have helped me.
It's not a DISCUSS level type of feedback, but I would appreciate ...

This is a useful addition to mail, a nice simple approach to solving the problem described.  Thanks for going through the SecDir review as well.

I still think the intermingling of the two mechanisms (SMTP extension and header field) in one document makes the document difficult to navigate and has the potential to cause implementers to miss important points. But I can't say that I'm convinced people will go astray, and all of the information you need to do the right thing is now in the document as far as I can tell. So I don't object to the publication of the document as-is.

I'm pretty sympathetic to Pete's concern about whether the doc discourages multiple recipients strongly enough.

I'm reading Bill's/Murray's responses as saying basically "this is already deployed, and the working group has explicitly decided to document what's deployed", and I think I've successfully convinced myself that if the mail contents were THAT confidential, you probably wouldn't send the same information about how to reset a password for one account to a herd of unrelated receivers.

So, thanks for having that conversation, so I can ballot no-obj.

(Sorry, I've not followed the loads of mail on this.
Apologies if I repeat something, in which case just ignore
me.)

- section 3, para 1: the header requires both the MDA and
someone else implement, presumably the sending UA, though I
guess a header can be added elsewhere.

- 14.3: I dislike the term used as the section title.
Software does not have any "sense of security" neither true
nor false. And the beliefs of senders "implementing" the
protocol aren't relevant. The beliefs of those deploying
implementations might be relevant, maybe but probably not.
I think all you need do here is re-iterate that the sender
is trusting the receiver with the message content
regardless.

- 15.1: "far fewer risks" is an odd phrase. I think you mean
"far lower oveall risk" maybe?