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 |