FPs and SA 3.2.0

[Julian Field]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Paul Bijnens wrote:
> On 2007-05-21 17:10, Julian Field wrote:
>   
>> Paul Bijnens wrote:
>>     
>>> On 2007-05-16 17:41, Julian Field wrote:
>>>       
>>>> I'll put it in the main codebase then. Perl has some very subtle bugs in 
>>>> it...
>>>>     
>>>>         
>>> I believe I don't need to teach perl to Julian (rather the other way
>>> around :-) ), but anyway...
>>>       
>>     
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>>   # JKF 3/10/2005
>>>>>>>>   my $temp = @HitList;
>>>>>>>>   $temp = $temp + 0;
>>>>>>>>   $temp = 0 unless $HitList[0] =~ /a-z/i;
>>>>>>>>   return ($temp, join(', ', @HitList));
>>>>>>>> }
>>>>>>>>
>>>>>>>> Let's see if that helps. According to the book, the 2 middle lines
>>>>>>>> shouldn't be needed at all.
>>>>>>>>             
>>>>>>>>                 
>>> To me this seems like the array @HitList contains an empty or undef
>>> value.  The match against "/[a-z]/i"   (or was that really intended
>>> "/a-z/i"??)
>>>       
>> No, your version would match against any string that contained the 
>> string "a-z" in it (in upper or lower case).
>>     
>
> Excuse me :-) but "/a-z/i" is your version and that will search for
> a string "a-z" lower or upper case.  My version, "/[a-z]/i", will match
> a name with at least one letter in it.  Which is what you're trying to
> do, I believe.
>   
It appears I owe you a rather large apology :-(
Sorry!
Many thanks for pointing out the error in my code. I have fixed it and 
put out a new beta with it fixed.

> You're effectively removing any RBL hits now, which is the main reason
> why no more FP's got hit by the current beta tester(-s? -- only one
> person as far I see had the problem).
>
> http://lists.mailscanner.info/pipermail/mailscanner/2007-May/073331.html
>
> I'm still interested in the exact list of RBLs in his config.
> Does it happen when 1 list is added? Two?  Some particular list only?
>
>
>   
>>>  just hides the source of the real error: getting an empty
>>> value for RBL name.
>>>       
>> If I printed the string of @HitList it turned out to have no contents, 
>>     
>
> How?    Something like:
>
>     @HitList = ( "" );	# somehow this ended up in the list
>     $temp = @HitList;
>     warn("HitList contains $temp entries: '@HitList'\n");
>
> No (visible) contents, but still one element in the array.
>
>
>   
>> so the scalar of it should have been zero. I have seen the problem of 
>> "0" not always equaling zero a few other times, hence the addition of 
>> zero to it to try to fix it, which has normally fixed the problem 
>>     
>
> You can have that problem with "" or undef, acting as 0 in calculations
> but not showing up as a "0" when printed. Indeed fixed by explicitly
> converting to number by adding "+ 0".
>
>   
>> elsewhere. The new modification has only been recently needed, the code 
>> has worked perfectly well for years (the previous version was very old 
>> code). If it had been needed before, people would have been complaining 
>> loudly about this for the past few years, and they haven't been. So if 
>> the start of the list doesn't contain a letter (all RBL names must 
>> contain at least 1 letter or they wouldn't work) then the list must 
>> actually be empty, so I force it to return zero.
>>     
>
> So we have to find out where the list element comes from that does
> not contain a letter, but is empty instead.  Instead of covering up the
> bug here.  (Still not convinced it is a perl bug.)
> Maybe most people use some RBLs at the MTA-level to block the incoming
> mail completely and/or use other RBLs in SA for scoring, and let the
> spam list entry in MailScanner empty.  Or the bug happens only on
> a timeout, like suggested in the OP problem, or only for certain
> combinations of timeout values, etc, etc.
>
>
>   
>>> Now finding out where the empty value is coming from, is -- at my
>>> current understanding of the code -- not yet successful.
>>>       
>> Yes. I have another demo of a Perl bug which I'll post for you if you 
>> like. Perl is not bug-free.
>>     
>
> Sure not.  But, speaking for myself, it's usually in my own
> programs, and not in the perl compiler, that I find the bugs.  :-)
>   
Agreed. But I have found the '$n=$n+0' trick solve a few problems in the 
past. Bugs that appeared on 1 user's system that I could not reproduce 
on my own systems. Adding 0 fixed it.

But yes, on the other hand, they have been rare (I think there's 2 in 
the whole of MailScanner, the most annoying was the spam score returned 
by SpamAssassin. It was generating 'not spam' reports where it clearly 
printed a spam score greater than the threshold. Add 0 to the number and 
then do the comparison again, and it produced the desired result.)


Jules

- -- 
Julian Field MEng CITP
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

MailScanner customisation, or any advanced system administration help?
Contact me at Jules at Jules.FM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
For all your IT requirements visit www.transtec.co.uk



-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.6.1 (Build 1012)
Charset: UTF-8

wj8DBQFGUgBVEfZZRxQVtlQRAuCSAKCPzzlzxJyUfJ1FqdtlwMQZhBKbwgCgphdD
DHyakLVp1DOcumPj8mJk/rs=
=5mpG
-----END PGP SIGNATURE-----

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
For all your IT requirements visit www.transtec.co.uk