>I guess my point is that spoofing/hacking is not likely to >happen.
As I wrote elsewhere, besides spoofing and hacking, the problem with SPF is that it'll be impossible to ever completely seal off the Internet such that it'll a) still be useful as it expands its reach and b) offers sufficient assurance that if some.domain.name.under.example.com.atlantis "permits" (via SPF records) emails sent from a given source, that source is not able to deliver forged emails. Actually, this really comes down to what kind of "forgery" is "stopped" by SPF. All sorts of forgery is still possible; certain kinds become a bit harder, so the spammers will move towards different kinds of forgery. I really doubt the expense will justify the rewards. >Making SPF dependent on IP address is not only bad politics, it is not >practical. Actually it won't work. Oh, that's for sure. I'm definitely not advocating that -- just pointing out that people's experiences with IP-keyed, DNS-based RBLs likely will reflect their *best* experiences with domain-name-keyed, DNS-based SPF. AFAIK, the essence of SPF is that, upon receiving an incoming email with an envelope sender of <[EMAIL PROTECTED]>, DNS-based SPF data for example.com is consulted to determine if the originating host of the email is permitted to send such email. That necessarily requires a domain-name-keyed lookup of DNS-based SPF data. The only way an IP address would be the key is if the envelope sender was <[EMAIL PROTECTED]>, i.e. an IP-address-based address. -- James Craig Burley Software Craftsperson <http://www.jcb-sc.com>
