Skip Menu |
 

This queue is for tickets about the Mail-SPF CPAN distribution.

Report information
The Basics
Id: 88390
Status: patched
Priority: 0/
Queue: Mail-SPF

People
Owner: JMEHNLE [...] cpan.org
Requestors: jhall [...] efolder.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Improper handling of SPF records with embedded newlines
Date: Tue, 03 Sep 2013 11:44:23 -0500
To: bug-Mail-SPF [...] rt.cpan.org
From: Jonathan Hall <jhall [...] efolder.net>
Download (untitled) / with headers
text/plain 1.4k
Occasionally one will encounter an SPF record with an embedded newline. Experience shows this is most common in include records. Examples (with " marks around the text portion, to make newlines more apparent). directadvantage.com. 3600 IN TXT "v=spf1 a mx a:sue.directadvantage.com include:postalproducts.com ~all" postalproducts.com. 86400 IN TXT "v=spf1 a mx mx:mail.postalproducts.com mx:po2.postalproducts.com mx:post.postalproducts.com ~all" And: rtdquality.us. 100 IN TXT "v=spf1 include:_incspfcheck.mailspike.net ?all" _incspfcheck.mailspike.net. 100 IN TXT "v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}.spfcheck.mailspike.net ?all " When this happens, Mail::SPF generates an invalid Received header, such as: Received-SPF: permerror (rtdquality.us ... _incspfcheck.mailspike.net: Junk encountered in record 'v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}.spfcheck.mailspike.net ?all ') receiver=doublecheck.co.douglas.nv.us; identity=mailfrom; envelope-from="edwin590@rtdquality.us"; helo=rtdquality.us; client-ip=212.126.98.234 This header causes Mail::Header to complain, as there is no space after the newline. Possible solutions: - Strip the newline(s) in the DNS resolver. - Strip the newline(s) in the output headers - Add a space after the newline in the headers (This would make the header 'valid' again, but seems sloppy, as the newlines are rather arbitrary) - Raise an error?
Download (untitled) / with headers
text/plain 474b
CR or LF characters are illegal in SPF records per http://tools.ietf.org/html/rfc4408#appendix-A and http://tools.ietf.org/html/rfc4234#appendix-B.1 . This is why Mail::SPF responds with a permerror. The fact that Mail::SPF::Result generates a Received-SPF header field containing CR or LF from the original record is a bug. The solution is for Mail::SPF::Result to sanitize the explanation string (which contains the original record). Will be fixed in the next release.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.