https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6338
--- Comment #11 from Mark Martinec <[email protected]> 2010-03-30 01:21:15 UTC --- (In reply to comment #6) > Now that I think of it, even the current (3.2, 3.3) code relies on a query > section of a reply packet matching exactly the query packet. This happens > to work on all mainstream DNS servers, but there is no guarantee for this > in a form of a RFC requirement. In essence, we are already depending on > poor-man's form of a dns0x20, just without any additional entropy. > > The 'dns_options dns0x20' could just as well default to true, without > breaking anything that isn't already broken. > > Does anybody feel we need to lift the requirement for an exact (case-for-case) > match when dns0x20 option is NOT enabled? Some poor soul on a cheap home > router/firewall/dns-server may be affected by this without knowing why > his SA DNS queries sometimes fail. trunk (3.4.0): Bug 4260: rewrite DNS code to use a single socket, event-based model; Bug 6338: Use of Bit 0x20 in DNS Labels to Improve Transaction Identity; Remove case sensitivity on DNS label in a query section when 'dns_options dns0x20' is NOT used - RFC 1035 does NOT require DNS server to preserve case in a query section of a reply, even though in practice all mainstream DNS servers do preserve it. In effect, code before this patch was half-way between dns0x20 and nodns0x20 setting. Sending lib/Mail/SpamAssassin/DnsResolver.pm Committed revision 928955. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
