Mark Andrews <marka@xxxxxxx> wrote:
>
>In message <7917527.VmCQD3a6Q3@scott-latitude-e6320>, Scott Kitterman
>writes:
>> On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
>> > I object to the removal of the SPF record.
>>
>> This is not a shock. You were in the rough when we discussed it in
>the WG
>> too.
>>
>> > Name servers already have access controls down to the granuality
>> > of TYPE. If this draft proceeds as currently described it is
>forcing
>> > name server vendors to access controls at the sub TYPE granuality.
>>
>> It's primarily an issue for applications. To the DNS, it's exactly
>what it
>> is, a TXT record.
>
>No. It isn't. By overloading TXT you prevent thing like this which
>existed before SPF was even dreamed up.
>
> update-policy {
> grant key-one subdomain example.net ANY
> deny key-two domain example.net SPF
> grant key-two domain example.net ANY
> };
>
> or
>
> update-policy {
> grant key-one subdomain example.net ANY
> grant key-two domain example.net TXT
> };
>
>Overloading a type is bad on so many levels which is why it was
>argued that SPF needed its own type. TXT is good for prototyping
>and that is about all.
>
> update-policy {
> grant key-one subdomain example.net ANY
> deny key-two domain example.net TXT/v=spf1
> grant key-two domain example.net ANY
> };
>
> update-policy {
> grant key-one subdomain example.net ANY
> deny key-two domain example.net TXT/v=spf1
> grant key-two domain example.net TXT!v=spf1
> };
This can be solved other ways. See my repky to your later message.
>> > With SPF lookup first I can specify the SPF policy using SPF and
>> > leave TXT free for other uses without having to worry about the
>> > records being misinterpeted.
>>
>> Unless you have some specific reason to be concerned about
>accidentally
>> starting an unrelated TXT record with "v=spf1 ", I can't imagine you
>don't
>> have more important things to worry about. This being a "problem" is
>a great
>> theory, but it just doesn't happen in practice.
>
>It's about being able to hand someone update control and not having to
>worry about them stuffing up the SPF records.
>
>> > SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for
>SPF.
>> > This is similar to not proceeding to A/AAAA lookups on MX lookup
>> > failures.
>>
>> Except that it's quite common for a SERVFAIL on TYPESPF to occur for
>a domain
>> that has an actual SPF record due to various operational issues.
>SERVFAIL on
>> type SPF doesn't reliably tell you anything about what a type TXT
>lookup would
>> produce. So it's similar, but only superficially so.
>
>And the worst that happens is that you let some *additional*
>potentially spoofed email through. This WG seems to treat this
>as a catastrophic errror when it isn't. This whole debate is
>because this working group treats not stopping one additional
>forgery as a catastrophic errror.
I prefer to design things for reliability rather than ignore interoperability problems.
>Note also that it will be the publishing site to blame for having
>a non RFC 1034 compliant server (it didn't respond to SPF queries)
>or misconfigured zone (returns wrong SOA in the negative response
>which can't happen when they have a SPF record).
Or some firewall in a box in between. Blame is not so easy to determine.
>> > I would also suggest that there be a sunset date published for the
>> > use of TXT for SPF.
>>
>> Do you also suggest creation of an Internet police force to enforce
>this?
>> What would be be mandatory minimum sentence?
>
>You just code the cut off date into the code that does the verification
>and stop making TXT queries. You code the date into the code that
>checks for missing SPF records and change the complaint.
Is there an example of this kind of approach working?
Scott K