Quoting Dean Brooks:
> Ok, installed 4.65 and immediately was hit with more integer
> annoyances and had to downgrade back to 4.63.
> 1. The variable $spam_score_int defaults to a blank value. Therefore,
> ${if >{$spam_score_int}{50}}
> 2. Any numeric tests against ACL variables will need to be fixed to ensure
> ${if >{$acl_m0}{100}}
This is actually the same issue. The change in 4.64 was compliant to the
spec, the old behaviour was an undocumented feature (aka: bug). See this
thread in the archives:
http://www.exim.org/mail-archives/exim-dev/2006-September/msg00035.html
The fix for your config would be:
${if >{${spam_score_int}0}{500}}
${if >{${acl_m}0}{1000}}
> 3. I can't seem to find a way to tell whether or not a value is a valid
> integer without resorting to regexes. I hope I'm missing something
That has nothing to do with 4.64:
# /usr/sbin/exim-4.63 -be
> ${if ={bla}{0}}
Failed: "bla" is not a number
> ${if >{${if isint{$spam_score_int}{$spam_score_int}{0}}}{50}}
Well, Exim is not a javascript interpreter :)
But this one could be a nice addition, though I'd guess it is not needed
very often.
> Actually, what I was hoping for is that all this nonsense of checking
> for valid integers in comparisons be removed, or at least allow a null
Error checking is an essential security feature. Simply using 0 or 123
when something like 123a456 comes up will bite you sooner or later.
I agree the change for empty strings is very good. OTOH, using an empty
string in integer comparisons is definitely a config flaw.
