wayne wrote:
I've mentioned this RFC2317 several times
I've found only one article back in June with keyword = 2317
and author = your address in gmane.mail.spam.spf.discuss:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/6647>
RfC 2317 is apparently about in-addr.arpa and IPv4 CIDRs
smaller than /24 with stuff like this:
128/26.2.0.192.in-addr.arpa NS ns.B.domain
129.2.0.192.in-addr.arpa CNAME 129.128/26.2.0.192.in-addr.arpa
Beats me where this should be related to parsing a domain-spec
in SPF sender policies. The idea to parse SPF directives is:
name => mechanism
name=foo => modifier
name:foo => mechanism with domain-spec foo
name/bar => mechanism with CIDR bar
name:foo/bar => mechanism with domain-spec foo and CIDR bar
That's clear in protocol-03 resp. draft-lentczner. It allows
for macros within (or instead of) foo, and it allows for the
dual-CIDR stuff like name:foo/31//127 or name:foo//127/31
It doesn't allow a slash within the domain-spec foo. If that
would be a problem Robert's idea %! could solve it. But who
uses something like 128/26.2.0.192.in-addr.arpa in a sender
policy with A, MX, PTR, or INCLUDE ?
If Mark wants to improve the spec. he could replace space by
slash near line 935 (or he adopts %! for this problem (???)):
| Hence, this facility cannot produce all characters that
| are legal in a DNS label, for example, the space or control
You almost certianly saw that post, otherwise you wouldn't
have found the draft.
You're talking about the article with this piece of text:
| I will also listen to people who haven't actually done any
| SPF development, but don't expect as much weight to be given.
Consequently I did not comment your private text, and looked
only for problems in the actual SPF spec.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200410/0588.html
: * In order to make the ABNF unambigous with respect to CIDR notations,
: Mark made some perfectly valid domain names unsupported, such as those
: used by RFC2317.
[...]
That's apparently not a quote from .../200410/0588.html, but it
gives me a new idea for a keyword search: s/2317/RFC2317/ Yes,
you mentioned 2317 in a second article before:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/10906>
That's where I found the link to pre2 for a side-by-side-diff.
At this time I didn't look for any details in your article,
because I had mentally plonked you after your rude attacks on
Mark's work for SPF. But I saw the added "POSIX" for the %{t}
macro, and checked it: time_t unsigned long should be okay.
But as you said you don't want input from others who are not
currently implementing SPF, and I certainly comply. Bye, Frank