https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6484
--- Comment #27 from D. Stussy <[email protected]> 2011-05-27 19:12:17 UTC --- Considering the discussion on the IETF message list, I suggest the following course of action: 1) Commit that which was committed to trunk also to 3.3.2 - as if it were IPv4 only (even though its not). That is, ignore the problem for now. We will have to accept the problem and perhaps NOT recommend usage of the DNS zones which have the problem. Since this patch also allows MULTIPLE zone lookups, that's the functionality I'm suggesting for 3.3.2. The patch has changes to both Util.pm and Plugin/ASN.pm. 2) Redesignate any further IPv6 fix for version 3.4 - awaiting an RFC which fixes the issue. (New bug # if agreed upon. Create a "todo" list file?) 3) In the meantime, we could try some sort of "quick and dirty" additional patch: If the queried address has a colon, only accept data which has a colon in the network address range. Also noted: The relay-country plugin in the example ASN failure came up with "XX" (for the first relay) while one of the DNS queries returned additional fields, one of which had the missing country. If we can guarentee that the two plugins are examining the same "first" ip address, we have a chance to take corrective action (which I suggest ONLY when the first relay-country is "XX"). Of course, we also have to validate that the third ASN response field is two upper-case letters only (as it is for cymru.com's results) before replacing "^XX" [note the regex] with something else. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
