There is no need for a specific RFC for that. An email message contains a Message-ID header, which will be recopied by email software in replies to this message, into the In-Reply-To and References headers. RFC 5322 describes these fields.
In order to leverage this mechanism into an antispam filter, then it suffices that your email sending software "remembers" the Message-ID of the emails it previously sent, and matches them in incoming emails, so as to identify responses. You can replace this "memory" by, yet again, a MAC (make the Message-ID consist of some random value and then a MAC computed over that random value), which would allow the automatic recognition of a "genuine" message ID without requiring actual storage. However, since message ID are normally generated by MUA (e.g. Thunderbird), it can be difficult to alter their generation mechanism.
Anyway, since this recognition of message ID is purely local to a site, it does not need to be an agreed-upon Internet-wide mechanism, hence the lack of RFC. Some MUA, like Thunderbird, embed automatic filters for "junk mail" and these filters already do this message-ID processing, which is easy since the MUA already stores a copy of every sent email, including the Message-ID. Other software can be used; e.g. see this answer based on procmail and formail (classic Unix-based tools for manipulating emails)/
The real problem with this strategy is that the notion of "a reply" as seen by computers is tied to whether the user pushed the "reply" button; that may be different from what the user himself thinks of as "a reply". Some people send a "reply" by sending a plain new email but remembering previous exchanges, and even referencing such previous emails in their prose. For the human user, this is a genuine reply, as has been done for millenia (a parchment, a clay slab, a papyrus does not have a "reply" button, and this never prevented people from replying to each other); but machines would have a hard time identifying these "replies" as such.
