[exim] bypassing exim string expansion with invalid addresse…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Cyborg
Datum:  
To: exim-users@exim.org
Betreff: [exim] bypassing exim string expansion with invalid addresses

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