RFC 7293

The Require-Recipient-Valid-Since Header Field and SMTP Service Extension

📅 published July 2014, from ietf

RFC 7293: The Require-Recipient-Valid-Since Header Field and SMTP Service Extension ✨

okay bestie, this is RFC 7293 🎀 It's from July 2014, written by W. Mills (Yahoo! Inc.) and M. Kucherawy (Facebook, Inc.). It's a Standards Track doc with ISSN 2070-1721, published by the IETF. Basically it's a real, official Internet standard that lets an email sender say "only deliver this to whoever owned this address back then" 💌

Abstract ✨

okay so this doc defines an extension for SMTP (the Simple Mail Transfer Protocol) called "RRVS" 🦋 Its whole purpose is letting senders tell receivers a point in time when the sender knew who owned the target mailbox. Why does that matter? Because it helps catch when mailbox ownership has changed, so mail doesn't end up with the wrong person 🙈 The doc also defines a header field called "Require-Recipient-Valid-Since", which can tunnel the request through servers that don't support the extension 🧚

The main use is automatically generated messages, like account statements or password change instructions, which might have sensitive info in them 🔐 It could be useful for other stuff too, though 💜

Status of This Memo ✨

This is an Internet Standards Track document 🌸

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚

You can check the current status of this doc, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7293 🔗

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this doc 📜 Code Components extracted from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⭐

Table of Contents ✨

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Description . . . . . . . . . . . . . . . . . . . . . . . . .   4
  3.1.  The "RRVS" SMTP Extension . . . . . . . . . . . . . . . .   5
  3.2.  The "Require-Recipient-Valid-Since" Header Field  . . . .   5
  3.3.  Timestamps  . . . . . . . . . . . . . . . . . . . . . . .   6
4.  Use By Generators . . . . . . . . . . . . . . . . . . . . . .   6
5.  Handling By Receivers . . . . . . . . . . . . . . . . . . . .   7
  5.1.  SMTP Extension Used . . . . . . . . . . . . . . . . . . .   7
    5.1.1.  Relays  . . . . . . . . . . . . . . . . . . . . . . .   8
  5.2.  Header Field Used . . . . . . . . . . . . . . . . . . . .   9
    5.2.1.  Design Choices  . . . . . . . . . . . . . . . . . . .  10
  5.3.  Clock Synchronization . . . . . . . . . . . . . . . . . .  11
6.  Relaying without RRVS Support . . . . . . . . . . . . . . . .  11
  6.1.  Header Field Conversion . . . . . . . . . . . . . . . . .  11
7.  Header Field with Multiple Recipients . . . . . . . . . . . .  12
8.  Special Use Addresses . . . . . . . . . . . . . . . . . . . .  13
  8.1.  Mailing Lists . . . . . . . . . . . . . . . . . . . . . .  13
  8.2.  Single-Recipient Aliases  . . . . . . . . . . . . . . . .  13
  8.3.  Multiple-Recipient Aliases  . . . . . . . . . . . . . . .  14
  8.4.  Confidential Forwarding Addresses . . . . . . . . . . . .  14
  8.5.  Suggested Mailing List Enhancements . . . . . . . . . . .  14
9.  Continuous Ownership  . . . . . . . . . . . . . . . . . . . .  15
10. Digital Signatures  . . . . . . . . . . . . . . . . . . . . .  15
11. Authentication-Results Definitions  . . . . . . . . . . . . .  16
12. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
  12.1.  SMTP Extension Example . . . . . . . . . . . . . . . . .  17
  12.2.  Header Field Example . . . . . . . . . . . . . . . . . .  17
  12.3.  Authentication-Results Example . . . . . . . . . . . . .  17
13. Security Considerations . . . . . . . . . . . . . . . . . . .  18
  13.1.  Abuse Countermeasures  . . . . . . . . . . . . . . . . .  18
  13.2.  Suggested Use Restrictions . . . . . . . . . . . . . . .  18
  13.3.  False Sense of Security  . . . . . . . . . . . . . . . .  18
  13.4.  Reassignment of Mailboxes  . . . . . . . . . . . . . . .  19
14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
  14.1.  The Tradeoff . . . . . . . . . . . . . . . . . . . . . .  19
  14.2.  Probing Attacks  . . . . . . . . . . . . . . . . . . . .  19
  14.3.  Envelope Recipients  . . . . . . . . . . . . . . . . . .  20
  14.4.  Risks with Use . . . . . . . . . . . . . . . . . . . . .  20
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
  15.1.  SMTP Extension Registration  . . . . . . . . . . . . . .  20
  15.2.  Header Field Registration  . . . . . . . . . . . . . . .  20
  15.3.  Enhanced Status Code Registration  . . . . . . . . . . .  21
  15.4.  Authentication Results Registration  . . . . . . . . . .  22
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
  17.1.  Normative References . . . . . . . . . . . . . . . . . .  23
  17.2.  Informative References . . . . . . . . . . . . . . . . .  23

1. Introduction ✨

email addresses sometimes get reassigned to a different person 👀 For example, when someone changes jobs, the address used by an ex-employee can get handed to a new employee. Or a mail service provider (MSP) might expire an account and then let someone else register the local-part that was used before. People who emailed the previous owner might not know the address has changed hands, so the mail can reach the correct address but the wrong recipient 😭 This is a big deal for transactional mail about purchases, online accounts, and stuff like that 💅

What we need is a way to flag an attribute of the recipient that tells the old owner apart from the current owner, if they're different. And it has to respect privacy too 🔒

Here's the vibe: the sender of the mail says how "old" the address assignment is expected to be. Basically the sender is saying, "I know the intended recipient was using this address at this point in time. I don't want this message delivered to anyone else." 🦋 The receiving system then compares that time with the point when the address was assigned to its current user. If the assignment happened later than the time in the message, there's a good chance the current user is not the right recipient 🙅‍♀️ The receiving system can then stop delivery and, ideally, notify the original sender about the problem 📣

The main application is transactional mail (account info, password change requests, and other automatically generated messages), not user-written content 💌 It could be useful in other contexts too. For example, a personal address book could record when an email address was added, and then use that time with this extension 📒

Because the use cases here are super tied to privacy, the Security Considerations (Section 13) and the Privacy Considerations (Section 14) are especially important 🚨 Pay special attention to the limitation described in Section 13.3!!

⚠️ bestie, read Section 13.3 before you do anything with this. It's the big limitation.

2. Definitions ✨

For a description of the email architecture, check out [EMAIL-ARCH] 🏛️

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] 🎀

3. Description ✨

To handle the problem from Section 1, a mail-sending client (usually an automated agent) needs to tell the server it's connecting to that it expects the destination address of the message to have been under continuous ownership (see Section 9) since a specified point time 🕰️ That time would be when the intended recipient gave the address to the message author, or maybe a more recent time when the intended recipient reconfirmed ownership of the address with the sender 🫶

There are two mechanisms defined here: an extension to the Simple Mail Transfer Protocol [SMTP] and a brand new message header field 🧚 The SMTP extension gives strong assurance that things get enforced, because it confirms support at each handling step for a message. It also gives you the option to demand support at all nodes in the message's handling path, and to return the message to the originator otherwise 🔁 The header field can be used when the Message Delivery Agent (MDA) supports this function, but an intermediary system between the sending system and the MDA doesn't. The header field does NOT give the same strong assurance, though, and it's more prone to exposing private info (see Section 14.1) 💀

The SMTP extension is called "RRVS" and adds a parameter to the SMTP "RCPT" command. That parameter says the most recent point in time when the message author believed the destination mailbox was under continuous ownership of a specific party ⏰ The "Require-Recipient-Valid-Since" header field works the same way: it includes an intended recipient together with a timestamp that means the same thing 💜

3.1. The "RRVS" SMTP Extension ✨

Extensions to SMTP are described in Section 2.2 of [SMTP] 📖

The name of the extension is "RRVS", short for "Require Recipient Valid Since" 🦋 Servers that implement the SMTP extension advertise an extra EHLO keyword of "RRVS". It has no associated parameters, introduces no new SMTP commands, and doesn't alter the MAIL command. Lowkey simple, honestly 🌸

A Message Transfer Agent (MTA) that implements RRVS can transmit or accept one new parameter to the RCPT command. An MDA can also accept this new parameter. The parameter is "RRVS", and its value is a timestamp expressed as "date-time" as defined in [DATETIME], with the added restriction that a "time-secfrac" MUST NOT be used ⛔ The timestamp MAY optionally be followed by a semicolon character and a letter (known as the "no-support action"). That letter tells the server what to do when a downstream MTA is found that doesn't support the extension. The valid actions are "R" (reject; the default) and "C" (continue) 🫣

Formally, the new parameter and its value are defined like this:

    rrvs-param = "RRVS=" date-time [ ";" ( "C" / "R" ) ]

So this extension increases the maximum command length for the RCPT command by 33 characters 📏✨

The meaning of this extension, when it's used, is described in Section 5.1 🎀

3.2. The "Require-Recipient-Valid-Since" Header Field 💌

okay so the general rules for where header fields can go in a message and what they look like are already spelled out in "Internet Message Format" [MAIL], so we're just building on that 🫶

using Augmented Backus-Naur Form [ABNF], the syntax for the field looks like this:

  rrvs = "Require-Recipient-Valid-Since:" addr-spec ";" date-time
         CRLF

"date-time" is defined in Section 3.3, and "addr-spec" is defined in Section 3.4.1 of [MAIL]. 💅

3.3. Timestamps ⏰

the header field version of this protocol uses a different format for the date and time than the SMTP extension does 👀 that's because message header fields have their own date and time style, and this keeps things consistent with how headers already work

using both date and time is intentional, bc it matches how current implementations usually store the timestamp and makes it easy to include the time zone 🌍 ngl, whether anything finer than the date is actually useful in practice is kinda up for debate 🤷‍♀️

4. Use By Generators 🎀

when a message is generated and its content is sensitive enough that an author or the author's ADministrative Management Domain (ADMD), see [EMAIL-ARCH], wants to protect against misdelivery using this protocol, it figures out, for each recipient mailbox on the message, a timestamp for when it last confirmed ownership of that mailbox 🔐 then it applies the SMTP extension when sending the message to its destination 🚀

in cases where the outgoing MTA doesn't support the extension, the header field defined above can be used to pass the request through that system 🫡 BUT, and this is a big but, the header field is only a "best-effort" approach to solving the goals, and it has some shortcomings 😬

  1. the positive confirmation of support at each handling node, with the option to return the message to the originator when end-to-end support can't be confirmed, will be unavailable 🙅‍♀️;
  2. the protocol is focused on affecting delivery (that is, the transaction) rather than content, so using a header field in the content is generally inappropriate 🙈;
  3. the mechanism can't be used with multiple recipients without accidentally exposing info about one recipient to the others (see Section 7); and
  4. there's a risk of the timestamp parameter getting forwarded, automatically or on purpose by the user (since user agents might not show that the header field is there), and then being exposed to unintended recipients. (See Section 14.4.) 😱

so the header field format MUST NOT be used unless the originator or relay has specific knowledge that the receiving MDA or an intermediary MTA will apply it properly 🛑 and in any case, it SHOULD NOT be used for the multi-recipient case 🙅‍♀️

using the header field mechanism is also further restricted by the practices described in Section 7.2 of [SMTP], Section 3.6.3 of [MAIL], and Section 7 of this document. 📚✨

5. Handling By Receivers 🧚

if a receiver implements this specification, then there are two possible evaluation paths 🛤️

  1. the sending client uses the extension, so there's an RRVS parameter on a RCPT TO command in the SMTP session, and the parameters of interest are taken only from there (the header field, if it's present, gets disregarded); or
  2. the sending client doesn't use the extension, so the RRVS parameter isn't on the RCPT TO commands in the SMTP session, but the matching header field might be in the message. 📨

when the continuous ownership test fails for transient reasons (like an unavailable database or some other condition that's likely temporary), the normal transient failure handling for the message gets applied 🔄

if the continuous ownership test can't be completed because the necessary datum (the mailbox creation or reassignment date and time) wasn't recorded, the MDA doing the evaluation picks a date and time to use, specifically the latest possible point in time when the mailbox could have been created or reassigned 🕰️ for example, that might be the earliest of all the recorded mailbox creation/reassignment timestamps, or the time when the host was first installed. if no reasonable substitute for the timestamp can be picked, the MDA rejects the message using an SMTP reply code (preferably with an enhanced mail system status code, see Section 15.3) that says the test couldn't be completed 🙃 then the message originator can decide whether to reissue the message without RRVS protection or find another way to reach the mailbox owner 💌

5.1. SMTP Extension Used 🌸

for an MTA that supports the SMTP extension, the requirement is to keep enforcing RRVS while relaying to the next MTA or the MDA 🔁

a receiving MTA or MDA that implements the SMTP extension declared above and sees an RRVS parameter on a RCPT TO command checks whether the current owner of the destination mailbox has held it continuously, far enough back to include the given point in time, and delivers the message unless that check comes back negative ✅ specifically, an MDA does the following before continuing with delivery:

  1. ignore the parameter if the named mailbox is known to be a role account, as listed in "Mailbox Names for Common Services, Roles and Functions" [ROLES]; and
  2. if the address isn't known to be a role account, and if that address hasn't been under continuous ownership since the timestamp specified in the extension, return a 550 error to the RCPT command. (See also Section 15.3.) 🚫

5.1.1. Relays 🔀

an MTA that doesn't do mailbox ownership checks, like an MTA sitting at SMTP ingress on an organizational boundary, SHOULD relay the RRVS extension parameter to the next MTA or MDA so it can be processed there 🏰

for the SMTP extension, the optional RRVS parameter defined in Section 5.1 tells the MTA what action to take when relaying a message to another MTA that doesn't advertise support for this extension 🤓 when that's the case and the no-support action wasn't specified or is "R" (reject), the MTA handling the message MUST reject the message by:

  1. returning a 550 error to the DATA command, if synchronous service is being provided to the SMTP client that introduced the message, or
  2. generating a Delivery Status Notification [DSN] to tell the originator that non-delivery happened, and then stopping any further relay attempts. 📬

an enhanced mail system status code is defined for these rejections in Section 15.3. 🏷️

see Section 8.2 for additional discussion. 👀

when relaying, an MTA MUST preserve the no-support action if the SMTP client used it. 🫶

5.2. Header Field Used 📝

a receiving system that implements this specification, when it gets a message with a "Require-Recipient-Valid-Since" header field and no matching RRVS SMTP extension was used, checks whether the destination mailbox owner has held it continuously, far enough back to include the given date-time, and delivers the message unless that check comes back negative 💖 here's how it goes, step by step:

  1. extract those Require-Recipient-Valid-Since fields from the message that contain a recipient for which no matching RRVS SMTP extension was used.
  2. discard any such fields that match any of these criteria:
    • they're syntactically invalid;
    • they name a role account as listed in [ROLES];
    • the "addr-spec" portion doesn't match a current recipient, as listed in the RCPT TO commands in the SMTP session; or
    • the "addr-spec" portion doesn't refer to a mailbox handled for local delivery by this ADMD. 🗑️
  3. for each field that's left, determine whether the named address has been under continuous ownership since the matching timestamp. if it hasn't, reject the message. 🙅‍♀️
  4. RECOMMENDED: if local delivery is being performed, remove all instances of this field before delivery to a mailbox; if the message is being forwarded, remove those instances of this header field that weren't discarded by step 2 above. 🧹

handling carries on normally once those steps are done, as long as no rejection happened 🌈

the final step isn't mandatory, bc not all mail handling agents can strip header fields, and there are sometimes reasons to keep the field intact, like debugging or digital signatures that could get invalidated by that kind of change 🔏 see Section 10 for additional discussion. 💅

if a message is going to be rejected within the SMTP protocol itself (instead of generating a rejection message separately), servers implementing this protocol SHOULD also implement the SMTP extension described in "Enhanced Mail System Status Codes" [ESC], and use the enhanced status codes described in Section 15.3 as appropriate. 🔥

implementing this the header field way is expected to be transparent to non-participants, since they'd typically just ignore this header field 🦋

this header field isn't normally added to a message addressed to multiple recipients 🙅‍♀️ the whole point is for an author to protect transactional or otherwise sensitive data meant for a single recipient, so generating independent messages for each individual recipient is normal practice 📩 see Section 7 for further discussion and restrictions.

5.2.1. Design Choices 🧠

the address in the field content is there to support the case where a message with this header field gets forwarded 💡 the specific use case goes like this:

  1. a user subscribes to a service "S" at date-time "D" and confirms an email address at their current location, "A";
  2. later on, the user wants to leave that location, so they create a new mailbox somewhere else, at "B";
  3. the user sets up address "A" to forward to "B";
  4. "S" builds a message to "A" claiming that the address was valid at date-time "D", and sends it to "A";
  5. the receiving MTA for "A" figures out that the forwarding in effect was set up by the same party that owned the mailbox there, so it concludes the continuous ownership test has been satisfied 🤝;
  6. if possible, the MTA for "A" removes this header field from the message, and either way, forwards it to "B"; and
  7. on receipt at "B", either the header field has been removed or it doesn't refer to a current envelope recipient, and in either case the MTA delivers the message. 🎉

Section 8 discusses some interesting use cases, like the one where "B" ends up forwarding the message further. 🧩

SMTP has never required any correspondence between the addresses in the RFC5321.MailFrom and RFC5321.RcptTo parameters and the header fields of a message, which is exactly why the header field defined here contains the recipient address the timestamp applies to 💜

5.3. Clock Synchronization ⏱️

the timestamp part of this specification supports precision at the seconds level 🫧 it's uncommon, but not impossible, for a clock at either a generator or a receiver to be incorrect, which could lead to a wrong result in the RRVS evaluation 😵‍💫

to minimize the risk of those wrong results, both generators and receivers implementing this specification MUST use a standard clock synchronization protocol, such as [NTP], to synchronize to a common clock. ⏰✨

6. Relaying without RRVS Support 🦋

okay so bestie, this is the part where the message is headed somewhere that doesn't know about RRVS yet 😭 Like, the message got the SMTP extension on the way in, but it's not being delivered locally. It needs to keep moving. The next MTA on the route might not follow this spec at all, and that's a whole thing 💀

So when the MTA holding the message sees that it's about to relay to a server that doesn't advertise this extension, it has to pick one of these three options:

  1. Decline to relay the message further, ideally sending a Delivery Status Notification [DSN] to say it failed 🙅‍♀️ (RECOMMENDED);
  2. Downgrade the data from the SMTP extension into a header field, as described in Section 6.1 below (SHOULD NOT unless the conditions in that section are satisfied, and only when the previous option isn't available) 🎀; or
  3. Silently keep delivering and drop the protection this protocol was giving 😬

Using anything other than the first option should be avoided, unless there's specific knowledge that relaying further with the weaker protections doesn't create undue risk. Literally the only time it's chill to downgrade is when you really, really know it's safe 🫶

6.1. Header Field Conversion

Let's say an SMTP server ("B") gets a message with one or more Require-Recipient-Valid-Since header fields from a client ("A"). That probably means "A" doesn't support the SMTP extension. Now "B" needs to relay that message to another server ("C"), so "B" becomes a client too. If "C" does advertise the SMTP extension, then "B" SHOULD delete those header fields and pass the same info along through the SMTP extension instead ✨ Heads up though: changing the header like this can affect later validation when it's delivered. For example, a hash of the modified header would come out different. That might be a valid reason for some operators to skip the delete step 💅

Now flip it. If "B" got a mailbox timestamp from "A" through the SMTP extension, and it has to relay on to "C", but "C" doesn't advertise the SMTP extension, then "B" SHOULD add a Require-Recipient-Valid-Since header field for the mailbox the message is being relayed to, along with the matching valid-since timestamp for it. The catch: "B" only does this if it doesn't reject the message. Rejection gets skipped when the client specifically said no to it (see Section 5.1.1). And "B" should only add the header if it has prior information that the eventual MDA, or some other intermediate MTA, supports this mechanism and can process the header field as described in this specification 🧚

The really careful usage warnings about the header field from Section 4 apply to this relaying mechanism too. If "B" got multiple mailbox timestamps from "A", the warnings in Section 7 also apply 🍓

7. Header Field with Multiple Recipients 💜

Okay, the header field version gets messy FAST, especially when one message has multiple recipients. Each recipient ends up with their own Require-Recipient-Valid-Since header field, with a different address and timestamp for each one 😵‍💫

Here's the thing about SMTP: a message with a bunch of these header fields could get handled in a single delivery attempt for several recipients. Like, if two of the recipients are on the same server. And if even one of them fails the check, the delivery fails for all of them. So the server has to do one of these:

  • reject the message when the DATA phase finishes, which means rejecting delivery to all recipients, or
  • accept the message when DATA finishes, and then send a Delivery Status Notification [DSN] message for each recipient that failed.

It gets even more confusing when a message goes to two recipients, "A" and "B", probably with different timestamps, and both of them get redirected to a shared address, "C". The author might not know who currently owns or has owned mailbox "C", or even that "A" and/or "B" got redirected at all. So one or both deliveries could fail at "C", and the author would be super confused, because as far as they know, they never sent anything to "C" 😭

And there's a bigger worry too: fanning out a message that carries timestamps for multiple users is obviously a concern. The more handling agents there are, the harder it is to keep tight control over that timestamp info 🔥

8. Special Use Addresses 🌈

In [DSN-SMTP], there's an SMTP extension that lets SMTP clients ask for DSNs and related info, so those reports can be as useful as possible. Section 5.2.7 of that document looks at what happens when the recipient is a mailing list. RRVS has similar concerns, so we're covering them here, using that document as a model 🫶

For every case below, a receiving MTA SHOULD NOT introduce RRVS in either form (the SMTP extension or the header field) if the message didn't arrive with RRVS in use. Adding it would be second-guessing what the message originator intended, and that could lead to a bad outcome 🙈

8.1. Mailing Lists

Delivery to a mailing list service counts as a final delivery 📬 When this protocol is in use, it's evaluated like any normal delivery. If the same mailing list has been running in place of the recipient mailbox since at least the timestamp given as the RRVS parameter, the message gets delivered to the list service normally. Otherwise, it isn't delivered.

Here's the important bit: the MDA passing the message to the list service needs to leave out the RRVS parameter, in either form (SMTP extension or header field), when it does that. Why? Because the list sending the message out to its subscribers is a brand new message that isn't covered by the previous transaction 💅

8.2. Single-Recipient Aliases

When an RRVS-protected message is delivered to an alias (standing in for a mailbox) and that gets relayed to a single other destination, the usual RRVS check happens 🎀 The continuous ownership test might pass here. For example, a regular user inbox might have been swapped for an alias for that same user, and the moment that happened is recorded somewhere the relaying MTA can query 👑

If the relaying system also confirms ownership of the new destination address, it SHOULD apply RRVS using whichever is later: that timestamp, or the one that came in with the message. This also means you can change the alias without breaking the protection RRVS offers ✨

If the relaying system has no time records for the new destination address, then the RRVS SMTP extension isn't used on the relaying SMTP session. The header field for the local alias gets removed, following Section 5 🧹

8.3. Multiple-Recipient Aliases

When an RRVS-protected message is delivered to an alias (standing in for a mailbox) and gets relayed to multiple other destinations, the usual RRVS check still happens, the same way as in Section 8.2. The MTA expanding that alias then decides which of the options listed in that section applies to each new recipient 🦋

8.4. Confidential Forwarding Addresses

In the cases above, the original author could receive rejections, like DSNs, from the final destination. That happens when the RRVS check (or any other check) fails and rejection is justified. The problem? Those rejections can reveal that a forwarding relationship exists between the original intended recipient and the real final recipient 👀

If that's a concern, the first delivery attempt should be handled like a mailing list delivery. RRVS gets evaluated, and then all RRVS information gets removed from the message before it's relayed to its true destination 🔒

8.5. Suggested Mailing List Enhancements

Mailing list services could store the timestamp when each subscriber was added to the list 🧚‍♀️ This spec could then be used together with that info to keep list traffic going only to the original subscriber. It stops messages from reaching a different person who now has the address that subscriber was added under. When a rejection caused by this spec comes back, the list service can remove that address from future distribution.

A mailing list service that receives a message containing the header field defined here needs to remove it before redistributing the message. That keeps the relationship between the message's author and the mailing list from being exposed 🤫

9. Continuous Ownership 🔑

For this spec, an address counts as having been under continuous ownership since a given date-time if any message sent to that address at any point since then would have gone to nobody except the owner at that date-time. So even if an address got suspended or disabled for a while, any mail that actually got delivered would have gone exclusively to the same owner. It's presumed that some kind of relationship exists between the sender and the intended recipient. There has probably been some confirmation process to establish ownership of the receiver's mailbox. But how that's determined is a local matter and outside this document's scope 🌸

Checking continuous ownership is done by running any query that establishes whether that condition holds for a given mailbox ✨

Determining continuous ownership of a mailbox is a local matter at the receiving site. The only possible answers to the continuous-ownership-since question are "yes", "no", and "unknown". What to do in the "unknown" case is up to local policy 🙃

For example, when control of a domain name changes hands, the new domain owner might not be able to tell whether the owner of the address has been under continuous ownership since the stated date-time, especially if the mailbox history wasn't transferred too (or was never kept in the first place). It's also "unknown" if the database holding mailbox ownership data is temporarily unavailable when a message arrives. In that case, normal SMTP temporary failure handling is the right move 😌

To avoid exposing account details unnecessarily: if the address has had one continuous owner since it was created, any confirmation date-time SHOULD be considered to pass the test, even if it's earlier than the account creation date and time. Section 13 goes into this more 💜

10. Digital Signatures 🖋️

Here's the rule: this protocol requires removing the header field (when it's used) upon delivery, except in exceptional circumstances. Now, if a message with the header field were digitally signed in a way that covered the header field, changing the message this way would break the signature. But the header field is only for tunneling, and the rest of the transport system should treat it as purely trace information 🕵️‍♀️

So, the header field MUST NOT be included in the content covered by digital signatures 🔥

11. Authentication-Results Definitions ✨

okay so [AUTHRES] is the thing that lets a message tell you the results of its authentication checks, using a header field. Section 15 adds RRVS to the list of methods that can be reported that way, plus the result names for it. Here's what each result name means 💅

  • none: The message had no recipient mailbox timestamp, either through the SMTP extension or the header field. Basically, this protocol wasn't in use at all 🫥
  • unknown: At least one form of this protocol was used, but nobody could figure out whether the recipient mailbox had continuous ownership. 🤷‍♀️
  • temperror: At least one form was used, but something went wrong during evaluation in a way that's temporary. Retrying later will probably get a real answer 🔄
  • permerror: At least one form was used, but something went wrong during evaluation in a way that can't be recovered from. Retrying later probably won't help 💀
  • pass: At least one form was used, and the destination mailbox was confirmed to have had continuous ownership since the timestamp given. Slay 🎀✨
  • fail: At least one form was used, and the destination mailbox was confirmed NOT to have had continuous ownership since the timestamp given. 😭

If a message has multiple recipients, you can report multiple results using the mechanism described in [AUTHRES]. Main character energy for every single inbox 👑

12. Examples 🧚

okay bestie, in these examples "C:" means data the SMTP client sends, and "S:" means what the SMTP server replies. The message content is CRLF terminated, but we've left that out so it's easier to read 🍓

12.1. SMTP Extension Example

  C: [connection established]
  S: 220 server.example.com ESMTP ready
  C: EHLO client.example.net
  S: 250-server.example.com
  S: 250 RRVS
  C: MAIL FROM:<sender@example.net>
  S: 250 OK
  C: RCPT TO:<receiver@example.com> RRVS=2014-04-03T23:01:00Z
  S: 550 5.7.17 receiver@example.com is no longer valid
  C: QUIT
  S: 221 So long!

12.2. Header Field Example

  C: [connection established]
  S: 220 server.example.com ESMTP ready
  C: HELO client.example.net
  S: 250 server.example.com
  C: MAIL FROM:<sender@example.net>
  S: 250 OK
  C: RCPT TO:<receiver@example.com>
  S: 250 OK
  C: DATA
  S: 354 Ready for message content
  C: From: Mister Sender <sender@example.net>
     To: Miss Receiver <receiver@example.com>
     Subject: Are you still there?
     Date: Fri, 28 Jun 2013 18:01:01 +0200
     Require-Recipient-Valid-Since: receiver@example.com;
       Sat, 1 Jun 2013 09:23:01 -0700

     Are you still there?
     .
  S: 550 5.7.17 receiver@example.com is no longer valid
  C: QUIT
  S: 221 So long!

12.3. Authentication-Results Example

Here's how the Authentication-Results header field can show the outcome of an RRVS evaluation 🦋

  Authentication-Results: mx.example.com; rrvs=pass
          smtp.rcptto=user@example.com

So what this is saying: the message showed up addressed to the mailbox user@example.com, the continuous ownership test ran using the timestamp that was provided, and the check passed. The timestamp itself is NOT revealed, so it stays private 🤫

13. Security Considerations 🔒

13.1. Abuse Countermeasures

Okay, this part is serious. The reply from a server running this protocol can reveal how old an existing email mailbox is. Putting countermeasures in place against probing attacks is RECOMMENDED 🚨 For example, an operator could keep track of how often this field shows up for a particular mailbox and watch which timestamps are being submitted for testing. If a bunch of different timestamps are being tried against one mailbox in a short time, the field could be ignored and the message silently discarded. We'll get into this more in Section 14.

13.2. Suggested Use Restrictions

If the mailbox in the field is known to have had only one continuous owner since it was created, or it didn't exist at all (under any owner) before the date-time in the field, then the field SHOULD be silently ignored and normal message handling should apply, so no info gets leaked 🙈 Fields like that are probably the result of a big mistake or an attack.

A message author using this spec might only include the header field for recipients who are also known to implement this spec. That way, they cut down the chance of revealing anything about the relationship between the author and the mailbox 🫶

If a whole domain changes hands, the new owner might not know what addresses the old owner assigned. So nobody can be sure an address never had a single owner, or whether it existed at all. In that situation, the unknown result is probably the right one 🤷‍♀️

13.3. False Sense of Security

Senders who use this protocol probably think their content is being protected because of it 🥺 But receiving systems might not implement this protocol correctly, or at all. Also, when a sending system uses RRVS, it's just making a request to the receiving system. That system could decide not to block delivery because of some local policy, or for legal or operational reasons, and then the security the sender was counting on is gone. This could mean the timestamp info in the protocol ends up getting revealed by accident 😬

All of this is more proof that senders are better off only using this protocol when they're sending to receivers they know and trust. 💅

13.4. Reassignment of Mailboxes

This spec exists because reusing or recycling email addresses is risky, and honestly it's an inherently dangerous practice ⚠️ Email addresses are normally not expected to change hands very often.

It is RECOMMENDED to leave a long stretch of time between mailbox owners, during which the mailbox accepts no mail. That gives message senders a chance to notice that the previous owner isn't at that address anymore 🌸

14. Privacy Considerations 🦋

14.1. The Tradeoff

Some MSPs let account names expire when they've gone unused for a long time, and that creates a choice between two kinds of privacy problems. One is way scarier than the other 😭 Automatically generated mail often carries authentication credentials, and those can unlock super sensitive info. If those credentials go to the wrong person after a mailbox changes owners, the previous owner's data could be exposed without them ever knowing or agreeing to it 💀 By comparison, the info a third party could see from the proposal in this document is limited to the mailbox's history. Since MSPs have already chosen to let mailbox ownership change hands without the prior owner getting involved, the info leaked by the extensions here is a much smaller risk than mail landing with the wrong party 🎀

14.2. Probing Attacks

Like we said above, using this extension or header field in probing attacks can reveal the history of a mailbox. It's really hard to predict the harm that leaking any private info can cause, so it's smart to take this kind of disclosure seriously, whether it happens by accident or because an attacker is probing 🕵️‍♀️ So yeah, it's worth repeating: putting countermeasures against this kind of abuse needs a lot of careful thought.

14.3. Envelope Recipients

The To and Cc email header fields don't have to match the envelope recipient set, and Cc might not even be there at all 🤔 But the algorithm in Section 3 needs the header field to contain a match for an envelope recipient before it can act on it. So using this spec can reveal some or all of the original intended recipients to anyone who can see the message in transit or when it's delivered 👀

For a message going to one recipient, this probably isn't a big deal. That's one of the reasons using this spec on multi-recipient messages is discouraged 🧚

14.4. Risks with Use

MDAs might not follow the recommendation to remove the header field defined here when messages get delivered, whether that's from ignorance or a mistake 😵 And since user agents often don't display every header field, a message could get forwarded to someone else who then accidentally has the content of this header field 📨

Also, a bad actor might spot either form of the RRVS protocol and assume it means the content is high-value 💰

15. IANA Considerations 🌈

15.1. SMTP Extension Registration

Section 2.2.2 of [SMTP] explains how to register a new SMTP extension. IANA has registered the SMTP extension using the details in Section 3.1 of this document ✅

15.2. Header Field Registration

IANA has added the following entry to the "Permanent Message Header Field Names" registry, following the procedure in [IANA-HEADERS]:

  Header field name: Require-Recipient-Valid-Since
  Applicable protocol: mail ([MAIL])
  Status: standard
  Author/Change controller: IETF
  Specification document(s): RFC 7293
  Related information:
    Requesting review of any proposed changes and additions to
    this field is recommended.

15.3. Enhanced Status Code Registration ✨

okay so IANA put three brand new codes into the Enumerated Status Codes table of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry" 💅 here they are:

  Code:               X.7.17
  Sample Text:        Mailbox owner has changed
  Associated basic status code:  5XX
  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-time.
  Reference:          RFC 7293
  Submitter:          M. Kucherawy
  Change controller:  IESG

   Code:               X.7.18
   Sample Text:        Domain owner has changed
   Associated basic status code:  5XX
   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-time.
   Reference:          RFC 7293
   Submitter:          M. Kucherawy
   Change controller:  IESG

   Code:               X.7.19
   Sample Text:        RRVS test cannot be completed
   Associated basic status code:  5XX
   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 cannot complete the requested
                       evaluation because the required timestamp was
                       not recorded.  The message originator needs to
                       decide whether to reissue the message without
                       RRVS protection.
   Reference:          RFC 7293
   Submitter:          M. Kucherawy
   Change controller:  IESG

Quick vibe check on these: X.7.17 is for when the mailbox owner has changed 😭, X.7.18 is for when the domain owner changed, and X.7.19 is for when the RRVS test just can't be finished because the timestamp never got recorded 💀. For that last one, the message originator is the one who gets to decide whether to resend without RRVS protection. Main character energy, honestly 👑

15.4. Authentication Results Registration 🦋

IANA also registered some stuff in the "Email Authentication Methods" registry, and the "Email Authentication Result Names" registry too:

Method:  rrvs

Specifying Document:  RFC 7293

ptype:  smtp

Property:  rcptto

Value:  envelope recipient

Status:  active

Version:  1
Codes:  none, unknown, temperror, permerror, pass, fail

Defined:  RFC 7293

Auth Method(s):  rrvs

Meaning:  Section 11 of RFC 7293

Status:  active

16. Acknowledgments 🫶

Huge shoutout to Erling Ellingsen, who came up with the idea in the first place. Literally the whole concept started with them 🌸

Reviews and comments came in from Michael Adkins, Kurt Andersen, Eric Burger, Alissa Cooper, Dave Cridland, Dave Crocker, Ned Freed, John Levine, Alexey Melnikov, Jay Nancarrow, Hector Santos, Gregg Stefancik, and Ed Zayas. Thank you all, you absolute legends 💖

17. References 📚

17.1. Normative References

These are the ones you really need to read to understand this spec 🔥

[ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.

[DATETIME] Klyne, G., Ed. and C. Newman, "Date and Time on the
           Internet: Timestamps", RFC 3339, July 2002.

[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., Ed., "Internet Message Format", RFC 5322,
           October 2008.

[NTP]      Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
           Time Protocol Version 4: Protocol and Algorithms
           Specification", RFC 5905, June 2010.

[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.

17.2. Informative References

These ones are more like extra reading if you want the deeper backstory 🧚

[AUTHRES]  Kucherawy, M., "Message Header Field for Indicating
           Message Authentication Status", RFC 7001, September 2013.

[DSN]      Moore, K. and G. Vaudreuil, "An Extensible Message Format
           for Delivery Status Notifications", RFC 3464, January
           2003.

[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
           Extension for Delivery Status Notifications (DSNs)", RFC
           3461, 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.

Authors' Addresses 🌈

Here's where you can find the authors 🎀

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
📦 where this page comes from