http://bugzilla.spamassassin.org/show_bug.cgi?id=4260
------- Additional Comments From [EMAIL PROTECTED] 2005-05-08 11:13 ------- I verified that the problem is still here by running a mass-check on Fedora Core 3. It was way too slow to test on my Cygwin system, much slower than I remember it being when I was testing this before. But just to make sure I first verified that mass-check on the Fedora system using an older rev ran at the same rate as with the current svn. I disabled SPF and got the same results, except a bit faster. No difference in the number of bogus rr warnings. It is an easy way to save 10% of the time to run one of these tests. A fallacy in my thinking about the solution to this problem could be that creating a new socket will select an unused port, randomising the port numbers, adding another 16 bits to the port/ID space for the queries. Now that is made explicit, I see that of course the port number will not be random unless there is a way of ensuring that it is. The OS has no reason to pick a different port than it has before if there is no current listener on the port. This whole scheme will fall apart if the source ports are cycling through the same, for example, four numbers. I see two solutions. One is to go with a hash to ensure no collisions. The other is to find a way to randomise the source ports that are used. Another mistake I apparently made was to forget to spend a few hours running mass-check after my last "fix". Somehow I thought I had checked this. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
