Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2014-07-03
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-06-23
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-06-18
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-04-21
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-04-19
11 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-11.txt
2014-04-18
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-04-18
10 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-04-18
10 (System) RFC Editor state changed to EDIT
2014-04-18
10 (System) Announcement was received by RFC Editor
2014-04-17
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-04-17
10 (System) IANA Action state changed to In Progress
2014-04-17
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-04-17
10 Amy Vezza IESG has approved the document
2014-04-17
10 Amy Vezza Closed "Approve" ballot
2014-04-17
10 Amy Vezza Ballot approval text was generated
2014-04-17
10 Barry Leiba Ballot writeup was changed
2014-04-17
10 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-04-17
10 Barry Leiba [Ballot comment]
All good now: thanks for working out the issues and adding more text to discuss the alternatives.
2014-04-17
10 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Yes from Abstain
2014-04-16
10 Pete Resnick
[Ballot comment]
I still think the intermingling of the two mechanisms (SMTP extension and header field) in one document makes the document difficult to navigate …
[Ballot comment]
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.
2014-04-16
10 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2014-04-16
10 Murray Kucherawy IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-04-16
10 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-10.txt
2014-03-27
09 Vijay Gurbani Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani.
2014-03-27
09 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2014-03-27
09 Barry Leiba
[Ballot comment]
I'm moving back and supporting Pete's DISCUSS, and intending to send the document back to the working group to split out the header-field …
[Ballot comment]
I'm moving back and supporting Pete's DISCUSS, and intending to send the document back to the working group to split out the header-field part.
2014-03-27
09 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Abstain from Yes
2014-03-27
09 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2014-03-27
09 Tina Tsou Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: David Black.
2014-03-27
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-03-27
09 Spencer Dawkins
[Ballot comment]
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 …
[Ballot comment]
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.
2014-03-27
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-03-27
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-03-27
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-03-26
09 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-03-25
09 Pete Resnick
[Ballot discuss]
The last time we had one of these "SMTP extension with a header field to tunnel it through things that didn't know about …
[Ballot discuss]
The last time we had one of these "SMTP extension with a header field to tunnel it through things that didn't know about the extension" documents (SMTP PRIORITY), we rewrote it to be two separate documents: The SMTP extension as standards track, and the header field with tunneling instructions. I'd really like to understand why this wasn't done here. It seems to me that the header field is a complete hack, and has potential for screwing up content signatures when stripped, potentially unnecessarily revealing information to the end user, and standardizing it encourages trying to tunnel the message instead of bouncing it when the SMTP extension fails.

- A lot of the considerations and problematic cases in this document are entirely because of the header field. If that was moved to its own document, the SMTP extension could be documented much more sanely. The document structure is a mess and hard to read because of all of the information regarding how to deal with the header field.

- The header field is only necessary and useful when a relay server does not support the extension *and* when some other relay or delivery server does support the extension. Unlike the PRIORITY extension, where it is in the interest of both the sending and the receiving system to get the tunneled information, here the main interest lies with the sender. So if I want to use this as a sender, I probably want to make sure that the remote end actually supports it; if it doesn't, more likely than not I'd rather get the bounce and decide what to do rather than have it tunnelled and hear nothing if it's not implemented at the receiving end. And my understanding is that, for the most part, SMTP is not being used nowadays with a lot of uncontrolled relays in between source and receiver. So it seems like a hack to use the header field to tunnel when the message is likely to go from the sender (who presumably has implemented the extension) directly to the administrative domain of the recipient (for whom you would presume that there would not be intermediate relays that didn't implement the extension when the delivery agent does).

- The document leaves open the question of whether to bounce the message or not when the extension is not supported. (It says "RECOMMENDED" to bounce.) That leaves the decision to the recipient. It seems much safer to make that decision the *sender's*. Why aren't there two extensions (or a parameter to the current extension) to allow the sender to express whether to bounce or to send it on even if it fails? That way, if the extension isn't there, the receiving server knows what to do, and the tunneling document could say, "MUST NOT use this header field unless you know that the MDA supports RRVS."

- Using the header field has the potential to leak information to the end user in a way that the extension simply can't. So not only will I get the message not intended to me, I'll also get information about the date that the old address was valid. I can't convince myself that there is a security problem here (would the sec folks like to take a shot?), but that seems like a handy piece of information to have for a social engineering attack. "Hi, this is Murray. My email address is blah@blah. I created my account at your bank on April 1, 2010." Maybe it's not all that useful, but it worries me. But the extension has no such problem.

I really think that the header field mechanism should, at a minimum, be moved to a separate document and described only as a tunneling mechanism. I'd rather see it go away completely, but I understand that people want that tunneling mechanism.

I'm having a hard time reviewing the rest of this document with this issue outstanding. I'd like to hear what the authors think before I complete my review.

(One specific review item: I think the document is not nearly strong enough on the question of multiple recipients. If an MSA or relay very close to the sender does the downgrade, thereby putting all of the recipients into the header of the message, you are potentially exposing lots of information to lots of people. I think this really needs to be a MUST NOT use the header field mechanism with multiple recipients.)
2014-03-25
09 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2014-03-25
09 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-09.txt
2014-03-25
08 Alissa Cooper
[Ballot comment]
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 …
[Ballot comment]
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"?
2014-03-25
08 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2014-03-24
08 Stephen Farrell
[Ballot comment]

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

- section …
[Ballot comment]

(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?
2014-03-24
08 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-03-24
08 Alia Atlas
[Ballot comment]
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 …
[Ballot comment]
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?
2014-03-24
08 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-03-24
08 Brian Haberman
[Ballot discuss]
I have no objection to the publication of this document, but I have a concern that needs to be discussed.

The guidance on …
[Ballot discuss]
I have no objection to the publication of this document, but I have a concern that needs to be discussed.

The guidance on time synchronization in section 5.3 is inadequate for the results this document is hoping for.  Two machines can use NTP and not be synchronized with one another.  If the two machines use NTP to synchronize to separate NTP servers, there is a chance their clocks will not be synchronized with one another.  The question is how large the differential will be between the reference clocks and the answer is "it depends".  But, in this case, saying "use NTP" is like saying "use IPsec".

Is it reasonable for generators and receivers of this option to synchronize to a common clock?
2014-03-24
08 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2014-03-24
08 Benoît Claise
[Ballot comment]
I should be missing something.

So a mail sending client is supposed to send "The last time the intended recipient was known to …
[Ballot comment]
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 ...
2014-03-24
08 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from No Record
2014-03-23
08 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-03-21
08 Alissa Cooper
[Ballot discuss]
In Section 9.2, I don't understand why the last two options for handling this case are given, and why the first option is …
[Ballot discuss]
In Section 9.2, I don't understand why the last two options for handling this case are given, and why the first option is not instead mandatory. The alias either belongs to the same user as the mailbox, or it doesn't. Why put the relay in the business of changing dates?
2014-03-21
08 Alissa Cooper
[Ballot comment]
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 …
[Ballot comment]
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"?
2014-03-21
08 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2014-03-21
08 Benoît Claise
[Ballot comment]
I should be missing something.

So a mail sending client is supposed to send "The last time the intended recipient was known to …
[Ballot comment]
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.
2014-03-21
08 Benoît Claise Ballot comment text updated for Benoit Claise
2014-03-21
08 Kathleen Moriarty
[Ballot comment]
This is a useful addition to mail, a nice simple approach to solving the problem described.  Thanks for going through the SecDir review …
[Ballot comment]
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.
2014-03-21
08 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-03-20
08 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document, but here are some pseudo-random thoughts...

---

Section 6 appears to contradict the …
[Ballot comment]
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.
2014-03-20
08 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-03-20
08 Murray Kucherawy IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-03-20
08 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-08.txt
2014-03-19
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2014-03-19
07 Barry Leiba Ballot has been issued
2014-03-19
07 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2014-03-19
07 Barry Leiba Created "Approve" ballot
2014-03-19
07 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-03-17
07 Shaun Cooley Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shaun Cooley.
2014-03-17
07 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-03-13
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shaun Cooley
2014-03-13
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shaun Cooley
2014-03-11
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2014-03-11
07 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-rrvs-header-field-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-rrvs-header-field-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about three of the actions requested in the IANA Considerations section of this document. 

IANA understands that, upon approval of this document, there are four actions which IANA needs to complete.

First, in the SMTP Service Extensions subregistry of the MAIL Parameters registry located at:

http://www.iana.org/assignments/mail-parameters/

a new SMTP extension is to be added as follows:

EHLO Keyword: RRVS
Description: Require Recipient Valid Since
Reference: [ RFC-to-be ]
Note:

Second, in the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers/

a new Message Header Field Name is to be registered as follows:

Header Field Name: Require-Recipient-Valid-Since
Template:
Protocol: mail
Status: standard
Reference: [ RFC-to-be ]

Currently the Permanent Message Header Field Names registry is maintained through expert review as defined in RFC 5226.

IANA Question -> We will need to initiate a request and send this to
the designated expert for review/approval.

Third, in the Enumerated Status Codes subregistry of the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry located at:

http://www.iana.org/assignments/smtp-enhanced-status-codes/

two new status codes are to be registered as follows:

Code: X.7.17
Sample Text: Mailbox owner has changed
Associated basic status code: 5
Description: This status code is returned when a message is received with a Require-Recipient-Valid-Since field or RRVS extension and the receiving system is able to determine that the intended recipient mailbox has not been under continuous ownership since the specified date.
Reference: [ RFC-to-be ]
Submitter: M. Kucherawy
Change Controller: IESG

Code: X.7.18
Sample Text: Domain owner has changed
Associated basic status code: 5
Description: This status code is returned when a message is received with a Require-Recipient-Valid-Since field or RRVS extension and the receiving system wishes to disclose that the owner of the domain name of the recipient has changed since the specified date.
Reference: [ RFC-to-be ]
Submitter: M. Kucherawy
Change controller: IESG

Fourth, in the Email Authentication Methods subregistry of the Email Authentication Parameters registry located at:

http://www.iana.org/assignments/email-auth/

a new authentication method is to be registered as follows:

Method: rrvs
Defined: [ RFC-to-be ]
ptype: smtp
Property: rcptto
Value: envelope recipient
Status: active
Version: 1

Currently the Email Authentication Methods subregistry is maintained through expert review as defined in RFC 5226.

IANA Question -> We will need to initiate a request and send this to
the experts for review/approval.

Fifth, in the Email Authentication Result Names subregistry also in the Email Authentication Parameters registry located at:

http://www.iana.org/assignments/email-auth/

six new result names will be registered as follows:

Code: none
Defined: [ RFC-to-be ]
Auth Method: rrvs
Meaning: The message had no recipient mailbox timestamp associated with it, either via the SMTP extension or header field method; this protocol was not in use.
Status: active

Code: unknown
Defined: [ RFC-to-be ]
Auth Method: rrvs
Meaning: At least one form of this protocol was in use, but continuous ownership of the recipient mailbox could not be determined.
Status: active

Code: temperror
Defined: [ RFC-to-be ]
Auth Method: rrvs
Meaning: At least one form of this protocol was in use, but some kind of error occurred during evaluation that was transient in nature; a later retry will likely produce a final result.
Status: active

Code: permerror
Defined: [ RFC-to-be ]
Auth Method: rrvs
Meaning: At least one form of this protocol was in use, but some kind of error occurred during evaluation that was not recoverable; a later retry will not likely produce a final result.
Status: active

Code: pass
Defined: [ RFC-to-be ]
Auth Method: rrvs
Meaning: At least one form of this protocol was in use, and the destination mailbox was confirmed to have been under constant ownership since the timestamp thus provided.
Status: active

Code: fail
Defined: [ RFC-to-be ]
Auth Method: rrvs
Meaning: At least one form of this protocol was in use, and the destination mailbox was confirmed not to have been under constant ownership since the timestamp thus provided.
Status: active

Currently the Email Authentication Result Names subregistry is maintained through expert review as defined in RFC 5226.

IANA Question -> We will need to initiate a request and send this to
the experts for review/approval.

IANA understands that these five actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2014-03-06
07 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2014-03-06
07 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2014-03-04
07 Tina Tsou Request for Last Call review by OPSDIR is assigned to David Black
2014-03-04
07 Tina Tsou Request for Last Call review by OPSDIR is assigned to David Black
2014-03-03
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-03-03
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Require-Recipient-Valid-Since Header Field and …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Require-Recipient-Valid-Since Header Field and SMTP Service Extension) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'The Require-Recipient-Valid-Since Header Field and SMTP Service
  Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-03-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an extension for the Simple Mail Transfer
  Protocol called RRVS, and a header field called Require-Recipient-
  Valid-Since, to provide a method for senders to indicate to receivers
  the point in time when the sender last confirmed the ownership of the
  target mailbox.  This can be used to detect changes of mailbox
  ownership, and thus prevent mail from being delivered to the wrong
  party.

  The intended use of these facilities is on automatically generated
  messages that might contain sensitive information, though it may also
  be useful in other applications.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-03-03
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-03-03
07 Amy Vezza Last call announcement was generated
2014-03-03
07 Barry Leiba Placed on agenda for telechat - 2014-03-27
2014-03-03
07 Barry Leiba Ballot writeup was changed
2014-03-02
07 Barry Leiba Last call was requested
2014-03-02
07 Barry Leiba Last call announcement was generated
2014-03-02
07 Barry Leiba Ballot approval text was generated
2014-03-02
07 Barry Leiba Ballot writeup was generated
2014-03-02
07 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2014-03-02
07 Murray Kucherawy Tags AD Followup, Doc Shepherd Follow-up Underway cleared.
2014-03-02
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-03-02
07 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-07.txt
2014-02-27
06 Barry Leiba IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2014-01-28
06 Barry Leiba State changed to AD Evaluation from Publication Requested
2014-01-28
06 Barry Leiba
Document Shepherd Writeup
“The Require-Recipient-Valid-Since Header Field and SMTP Service Extension”
(draft-ietf-appsawg-rrvs-header-field-06)
By J. Trent Adams
January 23, 2013.

1. Summary

The document …
Document Shepherd Writeup
“The Require-Recipient-Valid-Since Header Field and SMTP Service Extension”
(draft-ietf-appsawg-rrvs-header-field-06)
By J. Trent Adams
January 23, 2013.

1. Summary

The document shepherd is J. Trent Adams. The responsible Area Director is Barry Leiba.

This document defines an extension for the Simple Mail Transfer Protocol called
RRVS, and a header field called Require-Recipient-Valid-Since, to provide a method
for senders to indicate to receivers the time when the sender last confirmed the
ownership of the target mailbox.  This can be used to detect changes of mailbox
ownership, and thus prevent mail from being delivered to the wrong party.

The intended use of these facilities is on automatically generated messages that
might contain sensitive information, though it may also be useful in other applications.

The Applications Area Work Group (AppsArea WG) is requesting that the document
become a Proposed Standard.

2. Review and Consensus

The document has gone through 7 iterations, starting with the -00 draft published as
an I-D on August 18, 2013, and the most recent -05 version posted on January 10,
2014.  Each iteration represents updates to the document following discussion on the
AppsArea WG discussion list (apps-discuss@ietf.org).  There have been
approximately a dozen active contributors throughout the process, representing strong
engagement.

By way of example of the impact of the review by the AppsArea WG, the initial draft
focused on the addition of a header field within the message as a means to identifying
continuous ownership of the mailbox.  Through the conversation, however, it became
clear that the community felt it was more appropriate to perform the validation through
the addition of an SMTP extension.  At the conclusion of the discussion, the
document was updated and now includes an SMTP extension.

The -06 version includes clarifications and addresses issues that were brought up on
the list in response to a call for final comments.  The comments on the -05 version
were incorporated to the point where those who contributed them responded that they
were comfortable that the -06 version effectively addressed their comments.

As of this writing, the document appears to have reached consensus support and
it is the opinion of this shepherd that it is ready to be moved forward.

3. Intellectual Property

The document was developed within the AppsArea WG in which all contributions by
the participants, including the named authors, were made in conformance with BCPs
78 and 79 and the copyright of the document has been granted to the IETF Trust. 
The authors have further confirmed that they have no knowledge of any
encumbrances on their contributions, or any contributions made by other participants.

4. Other Points

The document requests the following be registered by IANA:

* The registration in the “Permanent Message Header Field Names” registry of a new
Header Field Name: “Require-Recipient-Valid-Since”.  This request is made to support
the header field option described in this document.  No expert review is required.

* The registration in the “SMTP Service Extension in the Mail Parameters” registry of
a new EHLO Keyword: ”RRVS”.  No additional parameters are being requested.  No
expert review is required.

* The registration of two additional “Enumerated Status Codes” within the “Simple Mail
Transfer Protocol (SMTP) Enhanced Status Codes” registry: One to identify when a
mailbox owner has changed, the other when a domain owner has changed.  At the
time of this review, the requested entries are: “X.7.17” and “X.7.18”.  No expert
review is required.

* The registration in the “Email Authentication Methods” table of the “Email
Authentication Parameters” registry of a new Method: “rrvs”, with a ptype: “smtp”, and
property: “rcptto”.  An expert review is required, though no expert reviewer has been
identified at this time.
2014-01-27
06 Amy Vezza Notification list changed to : appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rrvs-header-field@tools.ietf.org, jtrentadams@gmail.com
2014-01-25
06 Murray Kucherawy Changed consensus to Yes from Unknown
2014-01-25
06 Salvatore Loreto
Document Shepherd Writeup
“The Require-Recipient-Valid-Since Header Field and SMTP Service Extension”
(draft-ietf-appsawg-rrvs-header-field-06)
By J. Trent Adams
January 23, 2013.

1. Summary

The document …
Document Shepherd Writeup
“The Require-Recipient-Valid-Since Header Field and SMTP Service Extension”
(draft-ietf-appsawg-rrvs-header-field-06)
By J. Trent Adams
January 23, 2013.

1. Summary

The document shepherd is J. Trent Adams. The responsible Area Director is Barry Leiba.

This document defines an extension for the Simple Mail Transfer Protocol called
RRVS, and a header field called Require-Recipient-Valid-Since, to provide a method
for senders to indicate to receivers the time when the sender last confirmed the
ownership of the target mailbox.  This can be used to detect changes of mailbox
ownership, and thus prevent mail from being delivered to the wrong party.

The intended use of these facilities is on automatically generated messages that
might contain sensitive information, though it may also be useful in other applications.

The Applications Area Work Group (AppsArea WG) is requesting that the document
become a Proposed Standard.

2. Review and Consensus

The document has gone through 7 iterations, starting with the -00 draft published as
an I-D on August 18, 2013, and the most recent -05 version posted on January 10,
2014.  Each iteration represents updates to the document following discussion on the
AppsArea WG discussion list (apps-discuss@ietf.org).  There have been
approximately a dozen active contributors throughout the process, representing strong
engagement.

By way of example of the impact of the review by the AppsArea WG, the initial draft
focused on the addition of a header field within the message as a means to identifying
continuous ownership of the mailbox.  Through the conversation, however, it became
clear that the community felt it was more appropriate to perform the validation through
the addition of an SMTP extension.  At the conclusion of the discussion, the
document was updated and now includes an SMTP extension.

The -06 version includes clarifications and addresses issues that were brought up on
the list in response to a call for final comments.  The comments on the -05 version
was incorporated to the point where those contributed them responded that they
were comfortable that the -06 version effectively addressed them.

As of this writing, the document appears to have reached consensus support and
it is the opinion of this shepherd that it is ready to be moved forward.

3. Intellectual Property

The document was developed within the AppsArea WG in which all contributions by
the participants, including the named authors, were made in conformance with BCPs
78 and 79 and the copyright of the document has been granted to the IETF Trust. 
The authors have further confirmed that they have no knowledge of any
encumbrances on their contributions, or any contributions made by other participants.

4. Other Points

All references are in compliance with RFC 3967.

The document requests the following be registered by IANA:

NOTE: A previous version of this writeup noted some minor changes that needed to be
made to the identification and specific spelling of the registries expected to be
updated.  They have all been adequately addressed.

* The registration in the “Permanent Message Header Field Names” registry of a new
Header Field Name: “Require-Recipient-Valid-Since”.  This request is made to support
the header field option described in this document.  No expert review is required.

* The registration in the “SMTP Service Extension in the Mail Parameters” registry of
a new EHLO Keyword: ”RRVS”.  No additional parameters are being requested.  No
expert review is required.

* The registration of two additional “Enumerated Status Codes” within the “Simple Mail
Transfer Protocol (SMTP) Enhanced Status Codes” registry: One to identify when a
mailbox owner has changed, the other when a domain owner has changed.  At the
time of this review, the requested entries are: “X.7.17” and “X.7.18”.  No expert
review is required.

* The registration in the “Email Authentication Methods” table of the “Email
Authentication Parameters” registry of a new Method: “rrvs”, with a ptype: “smtp”, and
property: “rcptto”.  An expert review is required, though no expert reviewer has been
identified at this time.

As of this writing, there appear to be no naming collisions with the IANA requests.
2014-01-25
06 Salvatore Loreto State Change Notice email list changed to appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rrvs-header-field@tools.ietf.org
2014-01-25
06 Salvatore Loreto Responsible AD changed to Barry Leiba
2014-01-25
06 Salvatore Loreto IETF WG state changed to Submitted to IESG for Publication
2014-01-25
06 Salvatore Loreto IESG state changed to Publication Requested
2014-01-25
06 Salvatore Loreto Working group state set to Submitted to IESG for Publication
2014-01-25
06 Salvatore Loreto IESG state set to Publication Requested
2014-01-25
06 Salvatore Loreto IESG process started in state Publication Requested
2014-01-23
06 Trent Adams Changed document writeup
2014-01-23
06 Trent Adams Changed document writeup
2014-01-10
06 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-06.txt
2014-01-10
05 Murray Kucherawy Tag Doc Shepherd Follow-up Underway set.
2014-01-10
05 Murray Kucherawy IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2014-01-07
05 Murray Kucherawy Intended Status changed to Proposed Standard from None
2013-12-13
05 Murray Kucherawy WGLC ends January 10, 2014.
2013-12-13
05 Murray Kucherawy IETF WG state changed to In WG Last Call from WG Document
2013-12-13
05 Trent Adams Changed document writeup
2013-12-12
05 Trent Adams Changed document writeup
2013-12-12
05 Trent Adams Changed document writeup
2013-12-12
05 Trent Adams Changed document writeup
2013-12-12
05 Trent Adams Changed document writeup
2013-12-12
05 Trent Adams Changed document writeup
2013-12-11
05 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-05.txt
2013-11-20
04 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-04.txt
2013-11-14
03 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-03.txt
2013-11-06
02 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-02.txt
2013-10-21
01 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-01.txt
2013-08-18
00 Murray Kucherawy Document shepherd changed to jtrentadams
2013-08-18
00 Murray Kucherawy New version available: draft-ietf-appsawg-rrvs-header-field-00.txt