wayne wrote:
If you have, for example, 10 A records for a name, djbdns
will return a random selection of 8 of the 10.
Ugh. Is this "working as designed" (= allowed) or a "bug" ?
[redirect=neither-dot-nor-macro]
In the ABNF that I posted, this was "fixed" by adding a
comment.
[...]
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200507/0379.html
Unreadable, no idea why Web archives of mailing lists don't
use <pre>. But I got the subject, with that I found one of
my own articles in this thread in a local "posted" folder,
there I found one of your Message-IDs in the References, and
with that I got a somewhat more readable...
<http://mid.gmane.org/x4br5a4ki2(_dot_)fsf_-_(_at_)footbone(_dot_)schlitt(_dot_)net>
...and adding "/raw" to the resulting URL is really readable:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/17728/raw>
Oh, yes, the <macro-var> idea is fine, it solves the _second_
problem. I missed that in my reply:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/17729>
The _first_ problem is a hopeless case: %{i} is a <macro-var>
and still bogus if it's used instead of <toplabel>. Don't try
<unknown-mod-name> with a <prose-val>, that's dubious.
For imported terms a <prose-val> is fine, otherwise I hate it.
How about this:
unknown-modifier = name "=" macro-string
; a name not matching "redirect" or "exp"
Another idea:
unknown-modifier = unknown-mod-name "=" macro-string
unknown-mod-name = name ; neither "redirect" nor "exp"
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.
They have enough old I-Ds waiting in their queue. Apparently
there will be a separate state "RFC-EDITOR" before "AUTH48".
I'm not sure why there is still a "IANA". Even Received-SPF
made it already:
http://www.iana.org/assignments/message-headers/perm-headers.html
Bye, Frank