Sender ID defines a mechanism that can be used by Mail Transfer Agents (MTAs), Mail Delivery Agents (MDAs) and Mail User Agents (MUAs) to identify email senders that lie about who they are in message envelope headers such as From, Sender, Resent-From and Resent-Sender. At least one of two tests should be performed:
Sender ID extends the format of SPF record by declaring version 2.0 in the DNS TXT resource record and explicitly declaring which addresses to validate mfrom, pra or both:
"v=spf2.0/mfrom,pra".
Senders may publish either spf1 or spf2.0, or both records in their DNS. If no spf2.0 record exists, then receivers should interpret “v=spf1” record as “v=spf2.0/mfrom,pra”.
There are two algorithms of getting the PRA:
Today there are legitimate reasons why the Internet domain names used in SMTP commands “HELO” (“EHLO”) and “MAIL FROM” may be different from those of the sender of an e-mail message. Therefore, the later algorithm uses new SMTP extension “MAIL FROM” command parameter “SUBMITTER” that is meant to duplicate the message envelope “FROM” header email address at the protocol level.
Administrators who have already published “v=spf1” records SHOULD review these records to determine whether they are also valid for use with PRA checks. If the information in a “v=spf1” record is not correct for a PRA check, administrators SHOULD publish either an “spf2.0/pra” record with correct information or an “spf2.0/pra ?all” record indicating that the result of a PRA check is explicitly inconclusive.
Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem.