On Mon, 2004-04-12 at 17:34, Roy Badami wrote:
"Dustin" == Dustin D Trammell <dtrammell(_at_)citadel(_dot_)com> writes:
Dustin> Using the multi-string example where each element of the
Dustin> SPF record was in a separate string ("v=spf1" "a" "mx"
Dustin> etc..) in the zone file (I believe it was BIND), the
Dustin> implementation in question appeared to concatenate those
Dustin> strings with spaces when it loaded the zone file, and then
Dustin> served the record out as the single string.
It did? That wasn't evident from the original post, and if this in
the case then the nameserver was just broken.
Hrm... I thought it was accompanied by a corresponding dig that showed
it was served as a single string, but apparently it was not (see Ref).
I must have been thinking of something else I recently looked at. Just
to make sure, I recreated the same record in one of my BIND 9.2.2-P3
servers to make sure I knew how it was served up, and it is indeed
served as separate strings in the single txt record. That being the
case I retract my previous reasoning for my opinion, but I still
maintain the opinion that spaces should NOT be added when concatenating
the separate strings.
In any case, I don't think the SPF spec should spend too much time
concerning itself with describing nameserver bugs (though it may be
helpful to mention them in passing).
What's important is the semantics of the DNS records, not what
contortions you have to go through to get your faviourite broken
nameserver to serve the record you put in the zonefile correctly...
I agree, if the defined SPF behavior is to concatenate the strings
without adding whitespace, it is then up to the DNS administrators to
determine how to properly publish the SPF record so that their
nameserver serves it up correctly.
Ref:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200404/0065.html
--
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.