|
From: John E H. <jh...@ti...> - 2006-06-27 15:43:37
|
John Horne wrote at 13:05 +0100 on Jun 27, 2006: > I don't expect a deluge. How would someone know if the pyzor server was > timing out or not? Their spam would probably be filtered by other > methods (SARE rules, DCC etc). Only if the sysadmin actually looked, or > monitored, the log file would they see that no spam mail is being > flagged as hitting a pyzor check (in SA). They would then need to > investigate further if there was a problem with pyzor. For these reasons > I suspect others may be experiencing a timeout problem but perhaps don't > know it. Yes, you _can_ look in the logs, but you don't have to. I put this in my ~/.spamassassin/user_prefs add_header all Pyzor _PYZOR_ This puts the X-Spam-Pyzor header in each mail. You see headers like this: X-Spam-Pyzor: X-Spam-Pyzor: Reported 0 times. X-Spam-Pyzor: Reported 26 times. The first one happens when pyzor times out (there are lots of those). The second one happens when pyzor responds that this mail has not been reported to pyzor. The third one... well you get the picture. There is a threshold (5 reports by default) where SA fires the PYZOR_CHECK rule and awards spam points to the email. FWIW, pyzor ping shows that both servers I know about are alive. 66.250.40.33:24441 (200, 'OK') 82.94.255.100:24441 (200, 'OK') But responsiveness is typically spotty... sh -c 'i=10;while [ $i -gt 0 ]; do pyzor ping; i=$(expr $i - 1); done' 66.250.40.33:24441 TimeoutError: 66.250.40.33:24441 TimeoutError: 66.250.40.33:24441 (200, 'OK') 66.250.40.33:24441 TimeoutError: 66.250.40.33:24441 TimeoutError: 66.250.40.33:24441 (200, 'OK') 66.250.40.33:24441 TimeoutError: 66.250.40.33:24441 TimeoutError: 66.250.40.33:24441 (200, 'OK') 66.250.40.33:24441 TimeoutError: My spambox shows that quite a few spams (say 30-40%) are getting awarded the PYZOR_CHECK score. If there was work done to make pyzor less prone to timeouts, we'd probably see more. It'd be nice if it was better, but I still consider a tool worth including in my spam checks. In addition to the timeout issue, another thing that is missing is a way to revoke false positives. Hmmm... actually, it looks like only SA 2.63 is catching 30-40%. Another test using SA 3.1.1 showed far fewer hits (< 1%). Perhaps the older SA code used to do retries or some other change in the SA code is affecting this. This might be a coincidence in my sample set or an OS difference (two different OS versions used for the two tests), but at first glance it looks like a change in SA is the difference. It might be a question for the SA lists or a quick look at the source. Okay, after looking through the SA source... 3.1.1 uses a 5 seconds timeout by default. 2.63 uses 10. I'm going to try bumping up the 5 second timeout to see how it affects my hit percentage. Other than the timeout, the pyzor_lookup code looks similar on the surface. |