http://bugzilla.spamassassin.org/show_bug.cgi?id=4260
------- Additional Comments From [EMAIL PROTECTED] 2005-05-09 01:52 -------
> aren't we already dropping the bogus packets immediately?
Those are just the ones that we can tell are bogus because it is, e.g., a reply
to a query for a domain's nameserver that arrives in response to a URIDNSBL
lookup.
We don't have a way of catching collisions causing a wrong URIDNSBL result.
Actually that gives me an idea for the next several hour test: I could use a
hash and generate a warning for all dropped packets to see how much of a problem
there is that we are not seeing.
BTW, I just realized that we don't have to generate a hash explicitly. Right now
we use the ID as the key in a hash table that associates the packet with the
callback function that is supposed to process it:
$self->{id_to_callback}->{$id} = $cb; # in bgsend
and
my $cb = delete $self->{id_to_callback}->{$id}; # in poll_responses
If instead we keyed on $id . $host in bgsend and in poll_response get the host
name from the question section to key on $id . $host we would eliminate
collisions without any more code. The extra memory for the strings is only one
string for each backgrounded DNS query in a single message, then they are
cleaned up.
The reason I'm not $suggesting $id . $host . $type is because when I was testing
I noticed that $type sometimes is left to default in the call to bgsend and
shows up as different values in the reply, and I don't now offhand what to set
it to in bgsend. With port, id, and host name all matching I'm sure it will be
fine.
Does anyone see a problem with that?
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
