scott at kitterman
Jul 21, 2009, 4:40 AM
Post #23 of 23
(3292 views)
Permalink
|
On Tue, 21 Jul 2009 12:13:52 +0200 Alessandro Vesely <vesely [at] tana> wrote:
>Scott Kitterman wrote:
>>> Even hotmail.com's TXT records start with "v=spf1", and I wonder if
>>> they mean they should be interpreted as "spf2.0/mfrom,pra".
>>
>> You'd have to ask Hotmail about what they expect their SPF records are
meant to mean.
>
>They are careful to always send with an SPF-good envelope sender.
>Incoming mail that doesn't pass the check goes to Junk folders, marked
>with a white cross on red background. In their words:
>
> Windows Live Hotmail treats all messages that fail Sender ID and
> phishing tests as fraudulent and warns the user about opening these
> messages.
>
>That is the "silently drop" track, leading to unreliability.
>
Agreed. For most domains and most mail (80% is a figure I've seen before)
Mail From and From are the same. Even today most domains can avoid
worrying about Sender ID specifics.
People use SPF recoeds for all kinds of purposes. The fact that a
particular free email provider has documented their approach in a series of
experimental RFCs shouldn't affect our efforts.
As a practical matter trying to land clear non-spam in someone's inbox at
Hotmail is sufficiently stochastic even for mail that passes Sender ID that
I doubt it matters much either way.
>> RFC 4408
>> describes what SPF records are and the only use of which I am aware that
is suitable for
>> standardization.
>
>I assume that "use" means obtaining the result, since what to do with
>the result is currently in the site-policies limbo. I think SPF use is
>superior, in that sense. However, there are mail domains that apply a
>different semantics, and some people on this list publish specific
>spf2.0 records for them. Do you mean we can discard them because they
>are irrelevant?
Yes. They are part of a failed experiment. When I've seen statistics,
there just don't seem to be a lot of SPF2.0 records out there.
>> No, I don't think we have any obligation to deal with cleaning
>> up after Microsoft.
>
>We know M$ moves with the grace of an elephant in a crystal shop, and
>I wish they never begrudged the MARID. However, if cleaning up is a
>possible way to reach a clean state, we may consider it. One advantage
>of v3 is that it introduces such cleaning up nicely. We can tag some
>stuff as historic, but forgetting history is never recommendable. For
>comparison, rfc5321 still mentions a number of really really obsolete
>behaviors.
True, but they were at one time standardized.
>>> And how about the transition to SPF
>>> RRs exclusively? In case the new RFC will be a Proposed or Draft
>>> Standard, we will have to stick to that text for an eventual Full
>>> Standard.
>>>
>> Now you are describing something not backward compatible. That should
wait
>> for an eventual SPF v 3.
>
>http://www.openspf.org/Community/SPFv3-SPF-RR-exclusive describes a
>smooth transition. The current stance of requiring equal TXT and SPF
>records doesn't make much sense. An alternative would be to drop SPF
>records altogether; using TXT RRs labeled _spf.example.com would be
>more in tune with what similar protocols do.
>
>A smooth transition to SPFv3 from the record selection described in
>rfc 4406 is more problematic: in step 1 they discard all TXT records
>if any SPF RRs are found, before even looking at their versions.
>
>I'd guess it would take at least a four years span following the
>publication of a new RFC, to get a further SPF update. Possibly much
>more. What you reckon?
>
We've already had it for four years and deployment is nil. I don't expect
that to change.
All schemes like SPF start with a catch 22. No one will check for records
because there are none published. No one will publish records because no
one checks them.
The fact that Meng Wong was able to come up with a way to break that catch
22 in 2003/2004 was almost miraculous. SPF was not the first attempt in
this problem space, it was just the first to succeed. The only other
similar success of which I'm aware is DK/DKIM.
The pyspf library that I help maintain has supported type SPF since roughly
a week after it was assigned. After performance related complaints, type
SPF checking was turned off by default.
My online SPF record checker has checked for it since then. Beyond "What's
that?", I've never gotten any questiond about it.
I maintain several SPF related packages in Ubuntu. Neither C library
supports type SPF. No one has complained. The new (relatively) Perl
library, Mail::SPF, does SPF checking and you can't turn it off. I've had
performance complaints.
Moving to a subdomain, bumping the version string to V3, or switching to
type SPF only all reset the deployment clock and need to break through the
catch 22 I describe above. DK/DKIM are only succeeding because large
entities like Yahoo! and Cisco are investing in them and expending
engineering and 'political' resources to push them.
Unless you've got a solid plan for getting past the deployment catch 22,
then stick with what can be done with version 1. I do think changing to
specify both lookups are not required if a type SPF record exists is a
change that can be done in a backward compatible way. If deployment picks
up, then a future revision could go further.
I do agree an eventual SPF v 3 should be type SPF only.
The SPF project has no corporate backing or budget. I view our deployed
base of SPF records and SPF checking programs as the most valuable assets
of the project and we must be careful not to place them at risk.
Scott K
Whether you move
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
|
