Hej,
exim SEGVAULTs if one uses the following construct:
${if match_address{1.2.3.4}{1.2.3.4} {foo}{bar}}
I (now) know this may not do what is wanted anyway, but nevertheless a
SEGVAULT is a little bit clumsy. :o)
The problem exists with exim 4.50 and 4.54 from Debian, as well as with
the latest exim-snapshot.
With valgrind and exim-snapshot I get:
5925 address match: subject=1.2.3.4 pattern=1.2.3.4
==5925==
==5925== Invalid read of size 1
==5925== at 0x80A43CD: string_copylc
==5925== by 0x8083A58: check_address
==5925== by 0x8082EED: match_check_list
==5925== by 0x8083BEB: match_address_list
...
==5925== Address 0x1 is not stack'd, malloc'd or (recently) free'd
Looking at check_address() in match.c, one finds out the problem is the
"uschar *sdomain", which gets initialized at line 994:
sdomain = Ustrrchr(subject, '@');
At line 1151 it is used like this:
csb.subject = (cb->caseless)? string_copylc(sdomain+1) : \
string_copy(sdomain+1);
D'oh. This gives Address 0x1 passed to string_copylc, if there's no "@"
in the subject string.
I'm not quite sure how to solve this issue, maybe a PANIC would do the
trick, or maybe we should just [issue a warning and] return FALSE.
lg,
daniel