[note: I've cc:'ed this to SPF-discuss because I think they will find
it useful.]
In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0501100043230(_dot_)32345-100000(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:
There is a new I-D for the SPF email anti-forgery system available
for review.
...
While SPF mostly deals with the [2]821 SMTP level, it also relies
heavily on DNS to communicate between the domain owner, and the
email receiver. This I-D also makes provisions to create a new RR
that is just a clone of the TXT RR type. While I did not make it to
IETF-61, it is my understanding that Stephane Bortzmeyer made a
presentation on this subject during the DNSEXT session.
There have been apparently no reply. Does it mean that nobody see
solid problems and that there is a silent and rough consensus that
the I-D can move forward :-)
I wish. ;-)
I do see some problems, but I already raised them at spf-discuss.
But since you asked about it on namedroppers, I'll focus just list
what I do not like as far as dns is concerned:
Yes, William has made a very large number of very helpful comments
about the various SPF drafts. I've addressed many, but not all of
them.
1. The draft says that if SPF record is not found for say "sub.example.com",
that lookup should be made for zonecut record which would probably be
"example.com". This is done as a way to simulate *.example.com and provide
spf record for all subdomains (especially when they exist unlike "*"), but
I think the problem is that these default SPF record are not identified
any difernent as with "*" and its just normal spf record for that domain
that is always the default and one can not turn this off. I have proposed
instead using special prefix - possibly "*spf*" or just "**" so that
such records are clearly identified, this would also allow in the future
to add feature to dns server itself that it could substitute default on
its own instead of forcing client to do 2nd lookup each time.
The idea of using a special subdomain for the default SPF record has
been kicked around before. I know that Mark Lentczner (another I-D
author), and I talked about it a little bit. Going back over the
comments I made to you on the SPF-discuss list, I see that I didn't
talk about it.
The reason why I didn't say anything about it was because I don't have
very strong feelings about the subject either way. Right now, the SPF
I-D makes no mention of any special domain names or sub domains, so
I would kind of like to avoid creating one. Also, if mandating a
special subdomain will generate complaints about "breaking wildcards",
which is another subject I don't have strong feelings on, but others
do.
Another possiblity would be to create a different record at the top of
the zone, with a different version string of, say, "v=spf1-default".
Then you could do something like "v=spf1-default redirect=%{d}" if you
want to get the current semantics, or "v=spf1-default -all" to deny
all email coming from subdomains without SPF records. If the default
SPF record is really long and DNS packet space is limited, you could
use "v=spf1-default redirect=*spf*.%{d}" and get the semantics you
suggest.
Note: These default SPF records are should only be used in cases
where mail claims to come from a subdomain that email normally
shouldn't come from. The SPF spec says that domain owners should use
explicit SPF records for all other cases. So, extra DNS lookups
shouldn't be a huge problem. Legitimate email should never have the
overhead, and spammers would gain no advantage to using them.
2. I'm still not perfectly happy that SPF is reusing TXT and especially
that this draft has changed all examples to use TXT instead of SPF record
type. In my opinion SPF draft should promote new SPF record type a lot
more and have clearly defined "exit" strategy of moving away from TXT
records once new DNS RR has been issued.
As I've mentioned many times, I just don't see any practical migration
strategy for DNS RR usage. The implicit MX rule of using the A record
is still very much needed after all these years.
The language that is in the draft about using TXT RRs and SPF RRs was
something that Mark Lentczner worked out with "the DNS folks" during
the MARID WG process. (No, I don't know exactly who "the DNS folks"
were.) Yes, I did many (but not all) of the examples, but that is
because I don't see why deployment of name servers that support the
SPF RR type for many years.
-wayne