FPs and SA 3.2.0

--[ UxBoD ]-- uxbod at splatnix.net
Tue May 22 09:33:35 IST 2007


perhaps :-

$temp = 0 unless ($HitList[0] =~ /[0-9|a-z]/i);

to cover all eventualities?

On Tue, 22 May 2007 09:22:12 +0100, "--[ UxBoD ]--" <uxbod at splatnix.net>
wrote:
> Yeah apologies Paul I was tired :(  I am having a play around with the
code
> at the moment. What would happen though if a RBL was purely numbers ie.
> 12345 ?
> 
> On Mon, 21 May 2007 21:23:40 +0100, Julian Field
> <MailScanner at ecs.soton.ac.uk> wrote:
>> -----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
>> 
>> --
>> MailScanner mailing list
>> mailscanner at lists.mailscanner.info
>> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>> 
>> Before posting, read http://wiki.mailscanner.info/posting
>> 
>> Support MailScanner development - buy the book off the website!
>> 
>>
> -- 
> --[ UxBoD ]--
> // PGP Key: "curl -s http://www.splatnix.net/uxbod.asc | gpg --import"
> // Fingerprint: 543A E778 7F2D 98F1 3E50 9C1F F190 93E0 E8E8 0CF8
> // Keyserver: www.keyserver.net Key-ID: 0xE8E80CF8
> // Phone: +44 (0) 845 869 2749  SIP: uxbod at sip.splatnix.net
> 
> 
>
-- 
--[ UxBoD ]--
// PGP Key: "curl -s http://www.splatnix.net/uxbod.asc | gpg --import"
// Fingerprint: 543A E778 7F2D 98F1 3E50 9C1F F190 93E0 E8E8 0CF8
// Keyserver: www.keyserver.net Key-ID: 0xE8E80CF8
// Phone: +44 (0) 845 869 2749  SIP: uxbod at sip.splatnix.net


-- 
This message has been scanned for viruses and dangerous content by MailScanner, and is
believed to be clean.



More information about the MailScanner mailing list