https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8213
--- Comment #3 from Sidney Markowitz <sidney@sidney.com> ---
(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.
--- Comment #3 from Sidney Markowitz <sidney@sidney.com> ---
(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.