On Tue, 2004-07-27 at 19:38, Mike Leber wrote:
On Mon, 26 Jul 2004 Valdis.Kletnieks@vt.edu wrote:
On Mon, 26 Jul 2004 11:51:26 EDT, Gerald said:
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. -Doug