In <42FBBDD7(_dot_)7F3D(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote:
* djbdns only returns 8 RRs instead of the complete RRset
(e.g. add a warning that some resolvers are known to give
incomplete information and using them in conjunction with
SPF checks can lead to errors.)
Is this related to the output of `nslookup -q=any`, or what is
it about ?
djbdns only returns 8 RRs instead of the compete RRset. If you have,
for example, 10 A records for a name, djbdns will return a random
selection of 8 of the 10. So, if you use an "a" or "mx" mechanism,
and the sending MTA is one of the ones left out, you will get
incorrect results.
Personally, I think anyone who uses djb software gets what the
deserve.
* bugs in the ABNF
* "redirect=aaa" is accepted by 'name "=" macro-string'
instead of being rejected.
IIRC it's impossible to fix this, or do you have an idea ?
Maybe 'name "=" domain-spec' ?
In the ABNF that I posted, this was "fixed" by adding a comment.
* "a:ab%-" is accepted because <domain-end> uses
<macro-expand>
Yes, so what ? You can't kill _all_ semantical issues in ABNF.
This one is pretty easy to fix. It wouldn't be worth it if it was the
only thing.
all of these were fixed in the ABNF that I posted a while
back.
I recall only the last point (CIDR values). Please post it
again if it also addresses the other two points.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200507/0379.html
For what it is worth, I have had no indication that the RFC
editor has done anything with the SPF I-D.
Waiting for 2234bis.
Somehow I doubt that the RFC editor will have *zero* other comments on
the draft. Surely, they can't just be ignoring it until this
dependancy is resolved.
-wayne