CSV is Different
from SPF and Sender-ID

Purpose and Simplicity

CSV performs a single, direct function, involving localized administration. It assesses the latest-hop sending MTA client. Authentication and authorization rely only on the purported domain identity of that MTA and on the administrator of that domain. These are typically local to a single organization and often within the same administrative group.

The registered information for CSV is simple to create and involves more stable data.

By contrast, SPF performs a variety of functions, and may involve a wide range of identities, potentially crossing organizational and administrative boundaries. It can involve any number of MTA "hops", with a different set of hopes for each path from a sender to each recipient. Hence the registered information for SPF can be complex and need frequent updating.

Efficiency

CSV is able to authenticate and verify authorization for HELO/EHLO announcements within a single DNS lookup. SPF and Sender-ID typically require a large number of lookups.

Initial measurements of SPF usage cite many tens of lookups. Up to one thousand lookups are possible. (The new SPF "Classic" specification attempts to limit the maximum to 100.) Having to perform many queries produces substantial delays.  If SPF checking is performed during the SMTP session, this can dramatically affect performance.  If it is not performed during the session, the benefit of the validation is greatly reduced.

Addressing and Forwarding

CSV does not constrain addressing choices or handling sequences between the originator and final recipients. SPF and Sender-ID require special coordination with mail-forwarding sites, such as mailing lists and personal aliasing services.

SPF and Sender-ID can require restrictions on the RFC2821.MAILFROM, RFC2822.FROM, RFC2822.SENDER, RFC2822.RESENT-FROM, and RFC2822.RESENT-SENDER addresses. With the new specification for SPF "Classic", there also may be HELO/EHLO constraints due to inclusion of the DNS zone-cut location as an alternative location.  This use of the zone-cut is in conflict with previous published records prior to SPF- Classic and with the semantics of the DNS. Zone boundaries are supposed to be operational units, rather than user-visible.

Clarity and Safety

CSV has simple, straightforward mechanisms that are easy to understand and easy to administer. SPF records have proved difficult to create properly and there is even some question about the ways in which SPF and Sender-ID records are interpreted. Such confusion defeats interoperation and reliable email delivery.

Administrative Effort and Operational Risks

CSV uses a well defined and simple DNS SRV record, to assert authorization. It takes advantage of the automated return of the target addresses, for authentication. This single lookup creates no new security exploitation risks, such as for a process thread that utilizes the UDP port to multiplex results.

CSV supports a domain-wide default, to require all authorized MTAs to have an explicit CSV record. This makes it easy to cover all sub-domain names, including those for which there is no DNS record. SPF has a more complicated mechanism that is proving problematic to specify and use..

SPF and Sender-ID contain complex, active-content text scripts with macro-expansions, such as Include, Redirect and Exists, combined with elements of various mailbox addresses.  The script processing and extensive lookups from multiple name servers greatly increases DNS exposure to exploitation, as well as the likelihood of syntactic and semantic errors.