Mark Andrews <marka(_at_)isc(_dot_)org> 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