On 2008-06-17 at 10:31 -0500, George R. Kasica wrote:
> >On Mon, 16 Jun 2008 22:05:07 +0100, you wrote:
>
> >2008/6/16 George R. Kasica <georgek@???>:
> >> I'm in the process of helping a client upgrade their exim installation
> >> from 4.63 to 4.69. The compile of 4.69 went fine, however, there seems
> >> to be some issue in the configuration file with the syntax or format
> >> of the ACL rules etc. that has changed from 4.63 to 4.69 that causes
> >> basically all of them to fail.
> >
> >What you're interpreting as all of them failing is likely to be Exim
> >complaining that your config file references a feature (router,
> >transport or lookup) that hasn't been complied in to the new instance
> >of the binary. There's no inherent incompatability.
> >
> >Post the actual errors for more help.
> >
> 2008-06-16 12:05:08 1K8I8N-0002Ig-TA failed to expand condition "${if
> and { {eq{$h_X-Spam-Flag:}{YES} } {= {${lookup mysql{SELECT filterspam
> FROM vpopmail WHERE pw_name='${local_part}' AND pw_domain =
> '${domain}'}} }{1} }} {yes}{no}}" for mysql_spam router: integer
> expected but " " found inside "and{...}" condition
In Exim 4.64, checks for numeric overflow were added and the stronger
numeric enforcement broke some config; all the issues were believed
fixed, including this fix in Exim 4.66:
PH/01 [...]
(i) An empty string was always treated as zero by the numeric comparison
operators. This behaviour has been restored.
This is very literal in that the string must be empty. I guess that
before the problematic (but very necessary) patch, it let you use
whitespace in there too.
So your MySQL query is returning a whitespace and expecting this to be
treated as 0.
What values can the query return? Does it return the literal string "1"
when it matches? Your fastest fix, in that case, might just be to
change '=' (numeric equality) to 'eq' (string equality).
-Phil
