SPF is dead. Long live CSV !
Posted Jun 15, 2006 7:06 UTC (Thu) by copsewood
Parent article: SPF on vger
SPF is a good idea, but in my understanding a badly flawed implementation. This only protects the envelope Mail From (and maybe the HELO) header and (probably rightly) makes no attempt to protect the mail body From: . Trying to make the internal headers meaningful to the human mail recipient is Microsoft's take on this (Patented SenderID which they call SPF version 2) but this makes this concept even more complex and unworkable (as the XML SenderID format is too slow and unreliable in connection with DNS use). Mail authentication technologies which don't protect the body From: can still carry phishes which fool human mail recipients but which appear to authenticate at the MTA level. Technologies which do attempt to protect mail internal headers are more likely to break existing practice. For those wanting the complexity of full message as opposed to just envelope authentication, DomainKey signed mail makes more sense, but still has weaknesses in connection with misleading domain names.
Other than for helping with whitelisting known acceptable mail senders, which you will only be able to do for high volume senders you know and trust, SPF is little used in practice despite the very many domains which have published SPF records. Because of the forwarding problem mentioned in the article, SPF does not give clear enough automated filter choices for MTAs to know whether a domain that publishes a SPF record stating what its legitimate mail sending addresses are, should not appear on envelopes of email coming from elsewhere.
Having successfully implemented this, in my view CSV http://mipassoc.org/csv/
makes a lot more sense for a robust and straightforward MTA rejection-capable technology which ensures the domain of the MTA sending mail across administrative boundaries accepts responsibility for doing this. It solves many of the problems associated with SPF because CSV only concerns the domain in the HELO envelope header.
1. Any domain owner capable of publishing DNS for their domain can state an origin IP address for any subdomain claimed in the HELO header. Suppose someone is sending mail directly to your MTA from a dynamic IP host. Currently you would have good reasons to reject this based on an dynamic IP DNSBL. The collateral damage from this penalises hobbyists running their own mail setups from any dynamic IPs and even static IPs which PTR to script-generated domain names. However, if the HELO domain publishes a CSV record for this IP address and has a good reputation, with CSV you can safely accept this mail. If the HELO domain:
a. doesn't have an acceptable reputation based on an RHS DNSBL or
b. corresponds to a PTR subdomain of the IP block owner who uses CSV to state that mail from this domain subtree should not carry their domain name on HELO envelopes,
In either case your MTA can safely reject such messages.
2. When it becomes possible to establish the domain responsible for directly sending or relaying a message, collaboration determining domain reputations for automated filtering decisions will become much more reliable than trying to do the same job based upon IP addresses. Currently only the IP address on a spam says anything reliable about its origin, and this is usually a compromised Windows zombie. Trying to reject or filter on this basis is analogous to determining the origin of a single sand particle on a moving beach.
to post comments)