One of the reasons banks may not have published SPF records is that SPF
only checks for mail envelope forgery, while phishing is mainly a
problem of From-header forgery. SenderID addresses this gap in SPF;
hopefully the license issues surrounding SenderID can be resolved so
that RFC-2822 header protection is part of some workable MARID standard.
Frankly I do not see this as a problem. If the domain for envelope sender has
declared "-all" in SPF, then if the spammer forges the "From:", then anti-spam
will use the fact that "From:" and envelope sender (or Return-Path:) are not
the same, as another probablistic measurement.
So I really do not see Microsoft's PRA patent as a problem. Astute anti-spam
will NOT be using the "From:", "Sender:", and "Resent-Header:" in the same
algorithm as described by the PRA. Also as illustrated in a post recently by
another person, SenderID has same problem, because all spammer has to do is
insert a forged "Resent-Header:" and then forge the "From:" address. So
SenderID adds no protection to "From:" that we do not already get with SPF
classic.
There is no reason to hold back. Support SPF classic with "-all" and we
anti-spam vendors will take care of the rest.
But they can no longer masquerade as the domain names of legitimate
corporations, like aol.com, hotmail.com, etc. :) Provided they all get
onboard, of course, publishing -all records.
Therein lies the rub. We can probably get the important non-ISP domains to
declare "-all", so phishing will be eliminated, but closing the forgery hole
for the millions of other senders, will IMHO be impossible under SPF or ANY PER
DOMAIN anti-forgery.
But let that not deter us. Let us maximize SPF classic for what it is designed
for. Then we can evaluate whether we need a PER USER anti-forgery standard.
-Shelby Moore