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.
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?
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.
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?
-------------------------------------------
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