spf-discuss
[Top] [All Lists]

[spf-discuss] TXT records (was: spam.co.nz)

2006-08-30 17:40:58
Julian Mehnle wrote:
 
v=spf1 a mx ptr include:activehost.com\000

I ignore trailing nulls. In Windows, everything above the
Win32 API layer do this automatically. At the Win32 layer,
it comes naturally to strip trailing nulls since strings
are generally null terminated.
 
That's wrong.  That way you accept SPF records that are
rejected legitimately by standards-compliant SPF
implementations.  That will only cause confusion, so don't
do it.  Broken SPF records ought to be fixed sooner rather
than later.

ACK, but if he's working with an API where he never sees the
extraneous NUL it's bitter.  Some days ago I read a draft 
where TXT RRs were used for a completely different purpose,
some appletalk / bonjour magic to note properties of a
service in name=value pairs.

They use the "subdivisions" of TXT to delimit the individual
pairs.  In the SPF spec. it's explained how such strings have
to be concatenated without adding an intervening space.  If
that strategy is used with their stuff they'd get garbage:

0x03A=B0x05AA=BB would result in A=BAA=BB, and following their
spec. that would be a single name A with value BAA=BB.  Now
I'm curious:  Is the way how SPF handles TXT "unusual", or is
Apple idea (no explicit delimiter) a bad idea ?  In their I-D
the example was a single pair A=B, 

For details see draft-cheshire-dnsext-dns-sd-04.txt  They did
interesting things with domain labels, e.g. "embedded" dots 
are allowed, we don't have this.
 
Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

<Prev in Thread] Current Thread [Next in Thread>