Skip to main content

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]