Editing Sender ID (section)

==Standardization issues==
The ''pra'' has the disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. by inserting a <code>Sender</code> or <code>Resent-Sender</code>. The latter violates <nowiki>RFC 2822</nowiki><ref name="rfc2822">{{Cite IETF|last=Resnick|first=Peter W.|title=Internet Message Format|rfc=2822}}</ref> and can be incompatible with <nowiki>RFC 822</nowiki>.<ref>{{Cite IETF|last=Crocker|first=D.|title=STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES|rfc=822}}</ref>

With SPF, mailing lists continue to work as is. Forwarders wishing to support SPF only need to modify SMTP MAIL FROM and RCPT TO, not the mail. This concept is not new: with the original <nowiki>RFC 821</nowiki><ref>{{Cite IETF|last=Postel|first=J.|title=Simple Mail Transfer Protocol|rfc=821}}</ref> SMTP forwarders always added their host name to the reverse path in the MAIL FROM.

The most problematic point{{According to whom|date=March 2021}} in the core Sender ID specification is its recommendation to interpret <code>v=spf1</code> policies like <code>spf2.0/mfrom,pra</code> instead of <code>spf2.0/mfrom</code>. This was never intended by all published SPF drafts since 2003, and for an unknown large number of <code>v=spf1</code> policies an evaluation for ''pra'' could cause bogus results for many cases where ''pra'' and ''mfrom'' are different. This problem was the basis of an appeal to the [[Internet Architecture Board|Internet Architecture Board (IAB)]]. 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 <nowiki>RFC 2822</nowiki>.<ref name="rfc2822" />

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.<ref name=rfc6686/>