> > I think this will be the next best thing in E-mail. I'd love for that date
> > to be August 1 though.
> OK... Aug 1 is a weekish away. Check your inbound mail for today, and ask
> yourself how much you'd be losing if you started enforcing SPF today, and what
> percentage of the sites you get legitimate mail from are likely to deploy SPF
> tags this week.....
Just checking if I have this correct:
>From what I understand the fall back for SPF to use the MX record and then
the A record if that isn't found, which covers alot of the net, how much?
Does anybody have any SPF compliance measurements (exclude spam) from
their production mail servers that they can share?
One needs to know outbound addresses and not just those seen in
round-robin fashion of inbound machines. MX records are not a fix.
Organizations that have separate outgoing mail servers from incoming mail
servers will need to define SPF records.
There is an alternative. The BATV proposal would remove the need to
publish the SPF records, but SRV records for the outbound machines
should be published if to enjoy named accreditation.
Mail forwarding to other domains on a per user basis (i.e. using .forward)
without updating an organizations SPF record will fail the SPF check.
The SPF check is based on the envelope sender and not the message from, so
it won't break as many mailing lists as it would first seem.
It breaks all forwarding, whereas BATV does not.
> And then keep in mind that SPF is *known* to break certain types of mail
> reflectors and forwarding (argue all you want about whether such things are
> fundementally broken - they're still *in production use*)....
1 percent? 5 percent? 0.1 percent?
(of course this depends on all kinds of things)
Then the other question is do we have any kind of figures for how much
spam currently fails the SPF check in any known test?
Even if SPF doesn't end up blocking very much spam, if it blocked most
worms and viruses, that might be worth while.
The proposal in question is not SPF, but rather Sender-ID. There is a
big difference. Sender-ID will not stop either spam or phishing.
Sender-ID allows alternative identities just as likely to confuse
users. SPF could aid stopping some of the bounce, as it checked the
MAIL FROM parameter, but Sender-ID completely ignores MAIL FROM, so
bouncing continues. Neither Sender-ID or SPF could hope to stop zombie
machines. CSV, on the other hand, can stop both spam and zombies by way
of name based accreditation allowed to be aggressively vetted. CSV, the
other MARID proposal. :^) CSV, BATV and SPF, would be a winning
combination at ending both spam and viruses.