Comment 0 for bug 954936

Intermediate CNAMEs encountered while parsing SPF records confuse python-spf
into returning a hard error (domain has two or more type TXT spf records) when
really there is no second SPF record, and the existing one is indeed valid.

Discovered while manually looking at the SPF record for
"support.zendesk.com" (which was in turn included by the SPF record for
"dropbox.com"):

 $ /usr/share/pyshared/spf.py support.zendesk.com
 PermError: Two or more type TXT spf records found.

 $ host -t txt support.zendesk.com
 support.zendesk.com is an alias for www.shard-2.int.zendesk.com.
 www.shard-2.int.zendesk.com is an alias for www.pod-1.int.zendesk.com.
 www.pod-1.int.zendesk.com descriptive text "v=spf1 ip4:184.106.12.190
 ip4:173.203.47.176 ip4:173.203.47.177 ~all"

 $ /usr/share/pyshared/spf.py www.pod-1.int.zendesk.com
 v=spf1 ip4:184.106.12.190 ip4:173.203.47.176 ip4:173.203.47.177 ~all

In other words, the SPF record for www.pod-1.int.zendesk.com is valid, and
so is the one for support.zendesk.com, but the (double) indirection via
CNAME(s) causes an error.

The consequence is some domains with valid SPF records are perceived as
having faulty ones, and then depending on how SPF is used on the receiving
end, email messages from the affected domains may be mis-classified as spam
or outright rejected.

TEST CASE: using the existing package, do:

$ /usr/share/pyshared/spf.py support.zendesk.com

See the error that's generated:
PermError: Two or more type TXT spf records found.

Install the updated packages and repeat:

$ /usr/share/pyshared/spf.py support.zendesk.com

See that you now get the correct reply:
v=spf1 ip4:184.106.12.190 ip4:173.203.47.176 ip4:173.203.47.177 ~all