However, there are many similar email header fields that all contain sending party information; therefore Sender ID defines in RFC 4407[4] a Purported Responsible Address (PRA) as well as a set of heuristic rules to establish this address from the many typical headers in an email.
In the case of phishing or spam, however, the pra may be based on Resent-* header fields that are often not displayed to the user.
However, Sender-ID and SPF yield the same result in approximately 80% of the cases, according to a billion message analysis.
This concept is not new: with the original RFC 821[9] SMTP forwarders always added their host name to the reverse path in the MAIL FROM.
In response to another prior appeal the IESG already noted that Sender ID cannot advance on the IETF standards track without addressing the incompatibility with a MUST in RFC 2822.
[7] Various surveys performed in 2012, when SPF turned from experimental to proposed standard, showed that fewer than 3% of mail domains published specific requests for using the pra, compared to some 40~50% of mail domains using SPF.