The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
draft-ietf-appsawg-rrvs-header-field-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7293.
|
|
---|---|---|---|
Authors | William Mills , Murray Kucherawy | ||
Last updated | 2013-10-21 | ||
Replaces | draft-wmills-rrvs-header-field | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | J. Trent Adams | ||
IESG | IESG state | Became RFC 7293 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-appsawg-rrvs-header-field-01
Mills & Kucherawy Expires April 24, 2014 [Page 10] Internet-Draft Require-Recipient-Valid-Since October 2013 any owner) prior to the date specified in the field, then the field can be silently ignored and normal message handling applied so that this information is not disclosed. Such fields are likely the product of either gross error or an attack. A message author using this specification might restrict inclusion of the header field such that it is only done for recipients known also to implement this specification, in order to reduce the possibility of revealing information about the relationship between the author and the mailbox. If ownership of an entire domain is transferred, the new owner may not know what addresses were assigned in the past by the prior owner. Hence, no address can be known not to have had a single owner, or to have existed (or not) at all. 12. Privacy Considerations 12.1. Probing Attacks As described above, use of this header field in probing attacks can disclose information about the history of the mailbox. The harm that can be done by leaking any kind of private information is difficult to predict, so it is prudent to be sensitive to this sort of disclosure, either inadvertently or in response to probing by an attacker. It bears restating, then, that implementing countermeasures to abuse of this capability needs strong consideration. That some MSPs allow for expiration of account names when they have been unused for a protracted period forces a choice between two potential types of privacy vulnerabilities, one of which presents significantly greater threats to users than the other. Automatically generated mail is often used to convey authentication credentials that can potentially provide access to extremely sensitive information. Supplying such credentials to the wrong party after a mailbox ownership change could allow the previous owner's data to be exposed without his or her authorization or knowledge. In contrast, the information that may be exposed to a third party via the proposal in this document is limited to information about the mailbox history. Given that MSPs have chosen to allow transfers of mailbox ownership without the prior owner's involvement, the information leakage from the header field specified here creates far fewer risks than the potential for delivering mail to the wrong party. Mills & Kucherawy Expires April 24, 2014 [Page 11] Internet-Draft Require-Recipient-Valid-Since October 2013 12.2. Envelope Recipients The email To and Cc header fields are not required to be populated with addresses that match the envelope recipient set, and Cc may even be absent. However, the algorithm in Section 3 requires that this header field contain a match for an envelope recipient in order to be actionable. As such, use of this specification can reveal some or all of the original intended recipient set to any party that can see the message in transit or upon delivery. For a message destined to a single recipient, this is unlikely to be a concern, which is one of the reasons use of this specification on multi-recipient messages is discouraged. 13. IANA Considerations 13.1. SMTP Extension Registration IANA is requested to register the SMTP extension described in Section 3.1. 13.2. Header Field Registration IANA is requested to add the following entry to the Permanent Message Header Field registry, as per the procedure found in [IANA-HEADERS]: Header field name: Require-Recipient-Valid-Since Applicable protocol: mail ([MAIL]) Status: Standard Author/Change controller: IETF Specification document(s): [this document] Related information: Requesting review of any proposed changes and additions to this field is recommended. 13.3. Enhanced Status Code Registration IANA is requested to register the following in the SMTP Enhanced Status Codes registry: Mills & Kucherawy Expires April 24, 2014 [Page 12] Internet-Draft Require-Recipient-Valid-Since October 2013 Code: X.7.15 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 and the receiving system is able to determine that the intended recipient mailbox has not been under continuous ownership since the specified date. Reference: [this document] Submitter: M. Kucherawy Change controller: IESG 14. References 14.1. Normative References [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MAIL] Resnick, P., "Internet Message Format", RFC 5322, October 2008. [ROLES] Crocker, D., "Mailbox Names For Common Services, Roles And Functions", RFC 2142, May 1997. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. 14.2. Informative References [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [ESC] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. Mills & Kucherawy Expires April 24, 2014 [Page 13] Internet-Draft Require-Recipient-Valid-Since October 2013 Appendix A. Acknowledgments Erling Ellingsen proposed the idea. Reviews and comments were provided by Michael Adkins, Kurt Andersen, Alissa Cooper, Dave Cridland, Dave Crocker, Ned Freed, John Levine, Hector Santos, Gregg Stefancik, Ed Zayas, (others) Authors' Addresses William J. Mills Yahoo! Inc. EMail: wmills_92105@yahoo.com Murray S. Kucherawy Facebook, Inc. 1 Hacker Way Menlo Park, CA 94025 USA EMail: msk@fb.com Mills & Kucherawy Expires April 24, 2014 [Page 14]