http://bugzilla.spamassassin.org/show_bug.cgi?id=3997
------- Additional Comments From [EMAIL PROTECTED] 2004-12-08 00:04 ------- Subject: Re: SURBL FP on a particular domain name > ------- Additional Comments From [EMAIL PROTECTED] 2004-12-07 23:34 ------- > Anything that does name resolution will tell you if a particular domain is on > SURBLs or not at the time you check (same test works on other RBLs, usually > needing you to convert to an IP address first). It's not clear exactly what > the > problem is, but Dallas' observation that urirhsbl is trying to do NS and A > resolution on domains could be part of the cause. *Any* name resolution won't tell you for certain what the result was when the (intermittent) FP actually occurred though. You need to see for sure that you are getting a cached result (by knowing the remaining TTL) to ensure that it isn't a *new* query to the SURBL DNS servers. A new lookup would confirm a persistent FP in the SURBL DNS data, but an intermittent one (like the reports in this bug) obviously can't be detected by repeated (new) lookups. I expect that the FPs (that you have said have never been in SURBL) will turn out to not be in a system's DNS cache... not knowing for sure if the query was served from cache or not won't tell you that. There's also the unlikely case of an intermittent glitch in rbldnsd that would only be revealed by cached data. Being able to accurately say that SpamAssassin actually received a response to the query and either acted correctly or incorrectly, or that SpamAssassin never actually queried SURBL DNS for that domain would be a lot more helpful than the assumption that you are receiving a cached query (since that assumption doesn't even allow for the possibility of SpamAssassin failing to make the query). > Looking up the NS record of something.multi.surbl.org will get up to 35 > different name server IP addresses, some of which may have least significant > octets that could trigger a SURBL-like match. The source code for urirhssub > should be checked for things like that to see if it could result in an FP. > Looking up the NS record of wild URI domains could also have unpredictable > results depending on how the code reals with the resolutions. Again, if you can be sure that a manual query has been served from cache (which you won't know if you don't see the TTL, or something saying the result is authoritative) you can't be sure that SpamAssassin actually did a lookup on the A record, and not the NS record or not at all. Anyway, if somebody's going to make the effort to get some debug info in the limited window available, they might as well get as much useful, and certain, info as possible. Daryl ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
