https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8225
Bug ID: 8225
Summary: askdns TCP fallback not working with UDP truncated TXT
response
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Plugins
Assignee: dev@spamassassin.apache.org
Reporter: sid...@sidney.com
Target Milestone: Undefined
Created attachment 5940
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5940&action=edit
Patch to t/askdns.t that adds test for this bug
This bug is being opened after bug 8213 was closed with a fix for the same
problem that only works with the SPF plugin.
Net::DNS::Resolver has automatic fallback to a TCP query retry when a response
to a UDP query indicates that the reply has been truncated due to too large a
reply packet. SpamAssassin's custom subclass Resolver never included that
feature. The problem can be seen by creating an askdns rule
I've attached a patch to t/askdns.t that creates such a rule and demonstrates
the bug.
This rule fails to match if I run it with my network DNS set to 1.1.1.1
I noticed that with my normal settings using my local gateway for DNS it only
fails sometimes, as apparently my local nameserver can cache the full response
or something like that.
If we want to fix this, we might be able to do it just for askdns by having it
use resolver->get_resolver() like we did for SPF in bug 8213, or we can try the
more general but complicated and risky fix of adding TCP fallback to our custom
Resolver code.
The reasoning for fixing only askdns is that I don't see anywhere else where
this could be a problem. I haven't checked if our DNS RBL processing makes use
of the TXT records, but even if it does those would only be short one record
reason strings.
If anyone else notices some place that large DNS replies can be a problem,
please note it here, preferably with a test case that demonstrates it.
--
You are receiving this mail because:
You are the assignee for the bug.
