Gets confused by CNAMEs while parsing SPF records
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pyspf (Debian) |
Fix Released
|
Unknown
|
|||
pyspf (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Lucid |
Fix Released
|
High
|
Scott Kitterman | ||
Maverick |
Fix Released
|
High
|
Scott Kitterman | ||
Natty |
Fix Released
|
High
|
Scott Kitterman | ||
Oneiric |
Fix Released
|
High
|
Scott Kitterman |
Bug Description
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.
"dropbox.com"):
$ /usr/share/
PermError: Two or more type TXT spf records found.
$ host -t txt support.zendesk.com
support.
www.shard-
www.pod-
ip4:173.203.47.176 ip4:173.203.47.177 ~all"
$ /usr/share/
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-
so is the one for support.
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/
See the error that's generated:
PermError: Two or more type TXT spf records found.
Install the updated packages and repeat:
$ /usr/share/
See that you now get the correct reply:
v=spf1 ip4:72.81.252.18 ip4:72.81.252.19 ip4:208.43.65.50 ip4:72.81.252.20 ?ip4:209.68.4.105 ?include:
Changed in pyspf (Debian): | |
status: | Unknown → Fix Released |
Already fixed in precise.