[Bug 8213] TCP fallback not working with UDP truncated TXT response
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213 --- Comment #7 from Sidney Markowitz --- Giovanni has set up a subdomain txttcp.spamassassin.org with large TXT replies and created a test for this problem for the SPF case, in revision 1916164 As of now I expect creating an askdns rule for matching TXT on that subdomain will never succeed, so we have something to test against if we want to fix that too. % dig txttcp.spamassassin.org TXT ;; Truncated, retrying in TCP mode. ... ;; MSG SIZE rcvd: 1621 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 8213] TCP fallback not working with UDP truncated TXT response
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213 --- Comment #6 from Sidney Markowitz --- It's the rule in 72_active.cf askdns __PDS_SPF_ONLYALL _SENDERDOMAIN_ TXT /^v=spf1 \+all$/ This particular case isn't a big deal, because a domain with a very large number of TXT records is not likely to have a simple "v-spf1 +all" SPF record. But this does mean that askdns rules for TXT will not work with hostnames with such large replies to TXT queries. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 8213] TCP fallback not working with UDP truncated TXT response
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213 --- Comment #5 from Sidney Markowitz --- Turning on -D all seems to provide the hint: Mar 7 16:58:09.757 [87061] dbg: askdns: launching query (__PDS_SPF_ONLYALL): 53.com Mar 7 16:58:09.758 [87061] dbg: async: launching TXT/53.com, rules: __PDS_SPF_ONLYALL Mar 7 16:58:09.758 [87061] dbg: dns: bgsend, DNS servers: [1.1.1.1]:53 Mar 7 16:58:09.758 [87061] dbg: dns: attempt 1/1, trying connect/sendto to [1.1.1.1]:53 Mar 7 16:58:09.758 [87061] dbg: dns: providing a callback for id: 58925/IN/TXT/53.com Mar 7 16:58:09.758 [87061] dbg: async: starting: __PDS_SPF_ONLYALL, AskDNS, TXT/53.com (timeout 15.0s, min 3.0s) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 8213] TCP fallback not working with UDP truncated TXT response
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213 --- Comment #4 from Sidney Markowitz --- Correction, the query for TXT 53.com and the resulting info log about the reply being truncated happens whether or not I am using my local DNS server or 1.1.1.1. And it happens if I remove the SPF plugin, so there is something other than SPF that queries that hostname for TXT records, but it doesn't seem to be anything that requires a good reply for that query. It still would be good to know where that happens so we can verify if there is a use case in which a truncated reply to a TXT query will break something. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 8213] TCP fallback not working with UDP truncated TXT response
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213 --- Comment #3 from Sidney Markowitz --- (In reply to Sidney Markowitz from comment #1) > When I read over the comment history in bug 4620 Typo, should be bug 4260 (In reply to Giovanni Bechis from comment #2) > Works reliably with a rather new Net::DNS, it might have issues with older I tested on my macbook with various older versions of Net::DNS back as far as 1.10 and got the same results, did not get SPF pass without the patch, got SPF pass with the patch. To get the failure to happen without the patch I did have to set my computer's default DNS to be 1.1.1.1 instead of my local net's DNS server. If I'm interpreting the comments in bug 4260 correctly, this should not impact the issue with masschecks that is discussed there because Mail::SPF will not be reusing the sockets used by our subclass of Net::DNS::Resolver. If our Resolver is only used to query TXT records for RBLs we should not see those extra large reply packets like from 53.com that cause this problem. Note, when I do test with my local DNS server, I still see the log message info: dns: reply to 25637/IN/TXT/53.com truncated (EDNS 4096 bytes), 0 answer records There is something that is sending the query using our Resolver, but it can't be Mail::SPF and it doesn't seem to be anything important. Or can anyone figure out what besides Mail::SPF would query that TXT record so we can know for sure whether there is some bug still there? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 8213] TCP fallback not working with UDP truncated TXT response
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213 --- Comment #2 from Giovanni Bechis --- Created attachment 5939 --> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5939=edit Email with problematic spf I've added this commit https://github.com/apache/spamassassin/commit/1b39f34b4da74460125d9daeecebc667e8d5296f to fix/workaround this issue. Works reliably with a rather new Net::DNS, it might have issues with older versions. The attached email passes SPF tests with the patch applied but not with the patch reverted. $ dig +noanswer +nocomments TXT 53.com @1.1.1.1 ; <<>> DiG 9.18.24 <<>> +noanswer +nocomments TXT 53.com @1.1.1.1 ;; global options: +cmd ;53.com.IN TXT ;; Query time: 49 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP) ;; WHEN: Wed Mar 06 17:15:19 CET 2024 ;; MSG SIZE rcvd: 1545 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 8213] TCP fallback not working with UDP truncated TXT response
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213 Sidney Markowitz changed: What|Removed |Added CC||sid...@sidney.com --- Comment #1 from Sidney Markowitz --- I gather from bug 6910 and what I have gleaned from looking over the code, that SpamAssassin does not retry truncated UDP replies by sending a TCP query. If Mail::SPF correctly handles TCP fallback for truncated UDP replies, that would explain why the SPF plugin is able to work with domains that have huge TXT records even though the SpamAssassin's DNS processing logs those warnings. Looking back at the history of this, I think what happened is that Net::DNS did not reliably do what we needed and we implemented our own bgsend and bgread for asynchronous handling of DNS queries for RBLs. Our version did not implement TCP fallback from truncated UDP queries when that was added to Net::DNS. When I read over the comment history in bug 4620 I can see that it would not be easy to change much of this: I don't remember any of that stuff, and I wrote a good number of those comments and code almost 20 years ago! If someone can come up with a patch to use bgsend and bgread from Net::DNS::Resolver instead of our own version, and demonstrate that everything still works, that could be a solution. However, I would like to see that there really is a problem other than warnings in logs. Given that SPF processing is done by Mail::SPF which doesn't have a problem with TCP fallback, I want to see an example of a mail message that SpamAssassin fails on because of truncated UDP replies. -- You are receiving this mail because: You are the assignee for the bug.
