Editing Sender ID (section)

== Principles of operation ==

Sender ID is heavily based on [[Sender Policy Framework|SPF]], with only a few additions.

Sender ID tries to improve on SPF: SPF does not verify the [[Email#Message header|header]] addresses (of which there can be more than one) that indicate the claimed sending party. One of these header addresses is typically displayed to the user and may be used to reply to emails. These header addresses can be different from the address that SPF tries to verify; that is, SPF verifies only the "MAIL FROM" address, also called the envelope sender.

However, there are many similar email header fields that all contain sending party information; therefore Sender ID defines in <nowiki>RFC 4407</nowiki><ref name=":0" /> 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.

Syntactically, Sender ID is almost identical to SPF except that <code>v=spf1</code> is replaced with one of:
* <code>spf2.0/mfrom</code>{{Snd}}meaning to verify the envelope sender address just like SPF.
* <code>spf2.0/mfrom,pra</code> or <code>spf2.0/pra,mfrom</code>{{Snd}}meaning to verify both the envelope sender and the PRA.
* <code>spf2.0/pra</code>{{Snd}}meaning to verify only the PRA.

The only other syntactical difference is that Sender ID offers the feature of ''positional'' modifiers not supported in SPF. In practice, so far no ''positional'' modifier has been specified in any Sender ID implementation.

In practice, the ''pra'' scheme usually only offers protection when the email is legitimate, while offering no real protection in the case of spam or phishing. The ''pra'' for most legitimate email will be either the familiar From: header field, or, in the case of mailing lists, the Sender: header field. 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. To be an effective anti-phishing tool, the MUA (Mail User Agent or Mail Client) will need to be modified to display either the ''pra'' for Sender ID, or the Return-Path: header field for SPF.

The ''pra'' tries to counter the problem of ''phishing'', while SPF or ''mfrom'' tries to counter the problem of spam bounces and other auto-replies to forged Return-Paths. Two different problems with two different proposed solutions. However, Sender-ID and SPF yield the same result in approximately 80% of the cases, according to a billion message analysis.<ref name=rfc6686>{{cite IETF |title=Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments |rfc=6686 |author=[[Murray Kucherawy]] |year=2012 |publisher=[[Internet Engineering Task Force|IETF]]}}</ref>