Re: [spf-discuss] back to Reclassifying Sender ID and SPF as Historic -

Alex van den Bogaerdt wrote:
> The standard should IMHO acknowledge the current install base from the 
> experiment which was conducted. But that's just it: an experiment, which 
> was useful, and which should end.
That's also my feeling.

> I see two ways forward:
>
> 1: do not declare sunset for SPF-in-TXT. Do mention TXT in an 'historic' 
> section, but do not allow it in the protocol. Let the implementors 
> decide how long they should support the RFC4408 experiment. 
> Disadvantage: there will be DNS software which doesn't yet know how to 
> handle the SPF RR.
> 2: do declare sunset for SPF-in-TXT. Advantage: everybody agrees on what 
> time frame we're talking about. Disadvantage: if the protocol is 
> slightly different, both versions need to be discussed.
We need at least one difference, clarifying the mfrom,pra default of 
spf2.0. Since that is not part of the historical section, it is 
obviously valid in the SPF RR only. This kind of sunset does not 
indicate a future date, but it indicates a functionality.
As an example of added functionality, the new spec may add yet another 
scope, say vfrom (visible from), which is tougher than pra as it 
cannot be circumvented with resent-* headers. Roughly, let's say it 
mandates to check any @ in the From header, so that a value of 
"support @ paypal.com" <another(_at_)malware(_dot_)net> results in two lookups, 
and if any of those has a vfrom the check fails, or something to the 
same effect. Only banks and bots would want to declare that. Only SPF 
RRs should be looked up for that, as the old spec provides no vfrom. 
(However, some implementations SPF-check the From header already.)
> > That said, keeping the TXT records around is essential.  No matter how 
> > new people's DNS servers are, changing thousands (or millions?) of domains 
> > will require work to be done by a very large number of people, and updating 
> > their TXT RR to SPF RR is not likely to be on the top of their lists.
> What is essential is that SPF policies in TXT records go away, or at 
> least become obsolete. Checking for both RR's is a waste, keeping TXT 
> and not SPF is not good either (TXT records are used for other 
> purposes). That leaves keeping SPF records and stop using SPF policies 
> in TXT records.
The new functionality, as the one exemplified above, should be 
appealing for receivers. If they want it, they have to upgrade their 
DNS. And, if the upgrade is related to security, it may enjoy a 
quicker upgrade path.
Possibly, most receivers will continue trying TXT lookups after SPF 
fails, until the rate of success that they get that way is somewhat 
meaningful. When receivers find a TXT record, they apply the old 
specs. Changes to the protocol should be conceived so that it is 
relatively easy to revamp existing software in order to behave like so.


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