Hm, the directory may not exist yet and needs to be created. So that
cannot be used as a lookup.
Would it be the sketched SQL lookup then? Maybe already returning both
local_part and domain in one go. I could also concat the whole path in
SQL (wouldn't necessarily know how to do that with Exim).
-Yves
-------- Ursprüngliche Nachricht --------
Von: Jeremy Harris via Exim-users <[email protected]>
Datum: 2025-05-05 23:02 +02:00
Betreff: [exim] Re: Upgrading Exim to 4.94: $local_part vs. $local_part_data
On 2025/05/05 9:25 PM, Yves Goergen via Exim-users wrote:
This router, however, is only used if the local_part has been
successfully looked up by a prior SQL query. So by the time we're
here, I know that the value is valid.
What I'm not sure about is whether I can use the variable or should
use the same value from the database lookup instead.
Nope.
While you may know this, Exim does not - and has mechanics that stop you:
a string resulting from an expansion that uses tainted data
(here, both $local_part and $domain - having been supplied by a potential
attacker, they are not to be trusted) is also labelled as being tainted.
And then, a tainted value may not be further expanded (because that is an
attack route, cf. log4j). Using it as a file path counts as expansion.
So here's the usual method for detainting for a filename context:
we use the existing filesystem as the local, trusted, database
and we do a lookup in that database using the tainted data as a key.
sieve_vacation_directory = ${lookup {$local_part@$domain} \
dsearch,ret=full \
{/var/mail/sieve}}/vacation
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
