The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
Extracted elements (33)
The Require-Recipient-Valid-Since header field includes the recipient address alongside the timestamp because SMTP has never required correspondence between envelope recipients and message header addresses. Including the address allows the header field to remain actionable after forwarding: if the MTA for the original address satisfies the ownership test and forwards the message, the receiving MTA at the new address finds no matching envelope recipient and simply delivers normally.
The SMTP extension is preferred over the header field because it provides positive confirmation of support at each handling node and enables end-to-end rejection when support cannot be confirmed; the header field is 'best-effort' only, cannot guarantee enforcement, and is more prone to privacy exposure.
When a relay (B) receives a message with a Require-Recipient-Valid-Since header field and must forward to a server (C) that advertises RRVS SMTP extension support, B SHOULD delete the header field and instead convey the information via the SMTP extension. The reverse conversion—SMTP extension to header field—SHOULD only occur when the eventual MDA is known to support it.
A receiving MTA SHOULD NOT introduce RRVS (in either form) when relaying or expanding a message that did not arrive with RRVS in use, as doing so would second-guess the originator's intent and could produce undesirable outcomes.
An MDA implementing the SMTP extension MUST return a 550 error to the RCPT command if the destination address is not a role account and has not been under continuous ownership since the RRVS-specified timestamp.
An MTA that does not perform mailbox ownership checks SHOULD relay the RRVS extension parameter to the next MTA or MDA so it can be processed there.
Both generators and receivers implementing this specification MUST use a standard clock synchronization protocol such as NTP (RFC 5905) to synchronize to a common clock, minimizing risk of incorrect evaluation results due to clock skew.
Generators MUST NOT use the Require-Recipient-Valid-Since header field unless the originator or relay has specific knowledge that the receiving MDA or an intermediary MTA will apply it properly.
If the specified address has had only one continuous owner since creation, the RRVS check SHOULD pass regardless of whether the specified timestamp is earlier than account creation, to avoid unnecessarily exposing account details.
It is RECOMMENDED that receivers remove all instances of the Require-Recipient-Valid-Since header field prior to local mailbox delivery, or remove actionable instances prior to forwarding, to prevent inadvertent exposure of the timestamp and recipient relationship.
Role accounts as listed in RFC 2142 MUST be ignored when evaluating the RRVS parameter; the check is inapplicable to shared/functional mailboxes.
The date-time value in the RRVS SMTP extension MUST NOT include a time-secfrac component, restricting timestamp precision to whole seconds.
The Require-Recipient-Valid-Since header field MUST NOT be included in the content covered by digital signatures, since the field is used for tunneling purposes and is expected to be removed upon delivery.
The Require-Recipient-Valid-Since header field SHOULD NOT be used for the multi-recipient case due to the risk of exposing one recipient's timestamp information to other recipients.
When relaying, an MTA MUST preserve the no-support action ('C' or 'R') as originally specified by the SMTP client that introduced the RRVS parameter.
When the no-support action is unspecified or 'R' and a downstream MTA does not advertise RRVS support, the relaying MTA MUST reject the message by returning a 550 error to DATA or generating a DSN and terminating relay attempts.
MDAs may not remove the Require-Recipient-Valid-Since header field upon delivery, and user agents often do not render all header fields. As a result, the header field with its embedded timestamp and recipient relationship could be inadvertently forwarded to unintended parties. Additionally, a bad actor observing RRVS usage may infer that the message contains high-value content.
The privacy tradeoff favors RRVS: automatically generated mail (account credentials, password resets) delivered to a wrong party after mailbox reassignment poses far greater risk than leaking mailbox history information. MSPs that allow address recycling create the underlying vulnerability; RRVS exposes only limited metadata about mailbox history.
The Require-Recipient-Valid-Since header field can reveal the sender-recipient relationship and original intended recipient set to any party observing the message in transit or upon delivery, since it must contain an envelope-matching address to be actionable. This is one reason multi-recipient use is discouraged.
Continuous ownership is defined as: an address has been under continuous ownership since a given date-time if any message sent to it since that date-time would have been delivered exclusively to the same owner. Suspended or disabled addresses may satisfy this test provided no mail was delivered to a different owner. The only valid answers are 'yes', 'no', and 'unknown'.
For mailing list delivery, RRVS is evaluated against the list address as a final delivery. If the mailing list has operated continuously since the RRVS timestamp, delivery proceeds; however, the MDA MUST omit the RRVS parameter in either form when passing the message to the list service, as redistribution by the list constitutes a new message transaction.
Header field handling proceeds in four steps: (1) extract Require-Recipient-Valid-Since fields for recipients where no RRVS SMTP extension was used; (2) discard syntactically invalid, role-account, mismatched, or non-local fields; (3) reject the message if any remaining named address fails continuous ownership; (4) RECOMMENDED: remove the header field before local delivery.
The Authentication-Results header field (RFC 7001) can report RRVS evaluation results using the method name 'rrvs' with result values: none (protocol not in use), unknown (ownership undetermined), temperror, permerror, pass (continuous ownership confirmed), or fail (ownership not confirmed since timestamp).
The RRVS SMTP extension adds an EHLO keyword 'RRVS' and a new parameter to the RCPT command. The parameter value is a date-time timestamp indicating when the sender last confirmed the recipient mailbox was under continuous ownership. An optional no-support action ('R' for reject, 'C' for continue) may follow a semicolon.
This document registers the 'Require-Recipient-Valid-Since' header field in the IANA Permanent Message Header Field Names registry, applicable protocol: mail, status: standard.
This document registers the 'rrvs' method in the IANA Email Authentication Methods registry (ptype: smtp, property: rcptto, value: envelope recipient) and registers result codes none/unknown/temperror/permerror/pass/fail in the Email Authentication Result Names registry.
This document registers the SMTP service extension keyword 'RRVS' in the IANA SMTP Service Extension registry, with no associated EHLO parameters, no new commands, and no alteration to the MAIL command.
This document registers three enhanced SMTP status codes: X.7.17 ('Mailbox owner has changed' — continuous ownership test failed), X.7.18 ('Domain owner has changed' — domain ownership changed since specified date-time), and X.7.19 ('RRVS test cannot be completed' — required timestamp was never recorded). All are associated with 5XX basic status codes.
A server implementing RRVS can disclose the age of an existing mailbox through its responses, enabling probing attacks. Implementation of countermeasures is RECOMMENDED, such as tracking timestamps submitted for a given mailbox and ignoring the field (silently discarding the message) when a variety of timestamps are tried in rapid succession.
It is RECOMMENDED to have a substantial period of time between successive mailbox owners during which the mailbox accepts no mail, giving message generators an opportunity to detect that the previous owner is no longer at that address before a new owner takes over.
Senders face a false sense of security: RRVS is a request, not a guarantee. Receiving systems may not implement the protocol correctly or at all, or may override it for local policy or legal reasons. Senders should avoid RRVS except when sending to known, trusted receivers.
The Require-Recipient-Valid-Since header field is encoded as: `rrvs = "Require-Recipient-Valid-Since:" addr-spec ";" date-time CRLF`, where addr-spec is the recipient address and date-time uses the message header field date format from RFC 5322.
The RRVS SMTP parameter is encoded as: `rrvs-param = "RRVS=" date-time [ ";" ( "C" / "R" ) ]` where date-time follows RFC 3339 format. This increases the maximum RCPT command length by 33 characters.