Sender authentication for email has been the long-promised structural defence against spam and phishing. Through 2004 specific proposals have advanced; specific disagreements have emerged; the consolidated standard has not arrived. A status note.
This is a longer post because the trajectory is structurally important and the current state has multiple moving parts.
What is in deployment
Three specific proposals are visible in 2004.
Sender Policy Framework (SPF). Meng Wong's proposal. Domains publish DNS TXT records listing the IP addresses authorised to send mail for them. Receiving servers verify the source IP against the published list. The deployment is partial but growing; specific large mail providers have adopted it.
The trajectory through 2004 has been positive. SPF was approved as an Experimental RFC in 2004; specific corporate domains and some major receivers (notably AOL) are checking SPF records.
Sender ID. Microsoft's proposal, broadly compatible with SPF but with extensions including the Purported Responsible Address algorithm. Microsoft submitted Sender ID to the IETF MARID working group through 2004.
The trajectory has been complicated. The IETF MARID working group struggled with patent claims (Microsoft holds patents on PRA), with technical questions, and with the underlying disagreement about whether SPF and Sender ID should be merged. The MARID working group was effectively shut down in September 2004 without producing a consolidated standard. Microsoft continues to ship Sender ID in their products; broader adoption is bounded.
DomainKeys. Yahoo's proposal. Senders cryptographically sign outgoing mail headers using a private key; the public key is published in DNS; receivers verify the signature. The cryptographic approach is structurally different from the IP-based approaches of SPF and Sender ID.
The deployment is at early stages. Yahoo signs outgoing Yahoo mail; some other large receivers verify Yahoo signatures. The cumulative deployment is small but growing; specific cryptographic libraries for various mail servers have emerged.
Why none of these has consolidated
Three structural reasons.
The patent question is real. Microsoft's patents on Sender ID (specifically the PRA algorithm) have produced anxiety across the open-source community. Specific large open-source mail-server projects have declined to implement Sender ID because of the patent concerns. The IETF requires patent licensing for standards-track work; Microsoft's licence terms have been contested.
The technical approaches are genuinely different. SPF and Sender ID are IP-based; DomainKeys is cryptographic. The two approaches solve overlapping but different problems; neither dominates structurally. Sites that want comprehensive sender authentication have implemented both, which doubles the operational cost.
The deployment incentives are structurally weak. Sender authentication helps recipients more than senders. A sender that publishes SPF records receives no direct benefit; a recipient that checks SPF records receives reduced spam volume. The incentive asymmetry slows the deployment cycle.
What is happening operationally
Despite the lack of consolidation, partial deployment is producing some operational benefit.
Specific large receivers check SPF. AOL, Hotmail (using Sender ID), and several other large providers verify sender authentication where available. Senders who publish records benefit from improved deliverability; the cumulative effect is meaningful but bounded.
Specific large senders publish records. Most major commercial domains have SPF records; specific large senders are publishing DomainKeys signatures. The cumulative coverage is growing.
Mail-server software supports the standards. Recent versions of Postfix, Sendmail, and Exim include SPF or DomainKeys support. The deployment friction is lower than it was 12 months ago.
Anti-spam tools consume the signals. SpamAssassin and similar tools use sender-authentication signals as inputs to their scoring; the scores are not deterministic but are informative.
The cumulative effect is partial defence rather than structural defence. Specific phishing campaigns that forge sender domains are easier to detect; specific spam volumes are reduced; the underlying spam infrastructure is essentially unaffected.
What this means for operators
For mail-server operators:
Publish SPF records for your domains. Specific syntax is well-documented; the cumulative operational cost is bounded; the deliverability benefit at AOL and other SPF-checking receivers is real.
Verify SPF records on incoming mail. Modern Postfix, Sendmail, and Exim configurations support SPF verification. The configuration produces additional signal for spam-filtering decisions.
Consider DomainKeys for high-volume sending domains. The cryptographic approach has structural advantages over IP-based authentication; specific deployment at a sending operator produces deliverability benefits.
Do not deploy Sender ID without explicit understanding of the patent situation. Microsoft's licence terms are restrictive; specific deployments may be subject to licensing requirements; the cumulative legal risk is non-trivial.
For anti-spam infrastructure operators:
Use sender-authentication signals as inputs. The signals are not deterministic; the signals are informative when combined with other inputs.
Track the deployment trajectory. As more senders and receivers deploy authentication, the signal strength grows; the operational discipline should adapt.
What I am doing on my own infrastructure
For my own setup: SPF records published for my domains. SPF verification configured on inbound mail. The cumulative effect is small (low mail volume) but the discipline matters.
For client mail-relay deployments where I have advisory roles: SPF as standard; DomainKeys for high-volume domains where the deployment cost is justified; explicit avoidance of Sender ID until the patent situation clarifies.
What I expect over the next 18 months
Three predictions:
SPF deployment continues to grow. 85%, deadline end of 2005. The simple IP-based approach is operationally accessible; the deployment cost is bounded; the trajectory continues.
DomainKeys evolves toward broader standardisation. 70%, deadline end of 2005. The cryptographic approach has structural advantages; specific consolidation work is underway; broader deployment will follow.
Sender ID deployment stays bounded. 80%, deadline end of 2005. The patent question continues to slow adoption outside Microsoft's own infrastructure.
No consolidated standard emerges. 75%, deadline end of 2005. The structural conditions that prevented consolidation in 2004 have not changed; the IETF process is unlikely to produce a unified standard.
The cumulative trajectory is positive but slow. Sender authentication will continue to grow incrementally; the consolidated structural defence remains years away.
What this teaches more generally
The sender-authentication trajectory illustrates a structural pattern visible across the security field: standards convergence is hard when the participants have genuinely different interests. SPF's open-source roots, Microsoft's patent concerns, Yahoo's cryptographic approach — each is rational from the perspective of the originating organisation; the cumulative inability to converge is the structural cost.
For my own writing: more on this trajectory as the deployment continues. The cumulative archive of sender-authentication writing will inform future structural-standards conversations.
More in time.