Hi,
if you use the expansion operator "${address:<String>}" to filter spammers,
they can evade this, by using halve open adresses, a mailclient would fix.
Example:
some sql ... "${quote_mysql:${lc:${address:$reply_address}}}" regexp
entry ....
If you use a valid reply-to address i.e. "A To B" <a@???>
the above gets expanded to : "a@???" regexp entry
(the filed entry contaisn regex's you want to check against the address)
If you use an invalid reply-to address i.e. "A To B" a@???>
the above gets expanded to : "" regexp entry
Result: whatever you wanted to do there, fails.
A mailclient which sees a mail bypassed like this, may detect this
"mistake" and will extract "a@???" correctly.
According to the Exim docs, this behaviour is VALID.
I suggest to make the expansion more fault tolerant OR to give us a
function that explicitly tells us,
that the address used was invalid and not just empty.
Because ATM: ${address:""} == ${address:"<uidhksdf"}
Example:
some sql ... ( "${quote_mysql:${lc:${address:$reply_address}}}" regexp
entry or ${validaddress:$reply_address} = 'invalid' ) ....
or '= "0" ' instead of " invalid " if you like.
Sidenote:
When using $reply_address it will never be "" therefor this sql would be
a valid workaround:
( "${quote_mysql:${lc:${address:$reply_address}}}" regexp entry or
${address:$reply_address} = '' )
Remember: this is only valid if the string used can not be "" itself.
Thats why a new ${validaddress:<string>} would be handy.
best regards,
Marius
