> Ok, have had a 5 minute scan read ... seems that tainted data is a
> {potential} problem, but in my case the variables that I use to build a
> path in transport 'local_delivery':
> [...]
> have already been used as keys in a database look-up previously in the
> router that cause the transport to be called:
That's not how things work. The variable will stay tainted even when
looked up.
> Can we have, instead, a directive that allows us to assert 'untainted'
> over one or more variables:
Previously, a single lookup that checked both local part and domain to
let the router match was popular. Now that's fighting against the design.
Use two lookups, one for local_parts and one for domains, even if both
perform the same lookup, to set $local_part_data and $domain_data as
side effect, and things are easy from there. It's a new way of thinking
about routers: You do not just need a condition to let the router match
the address, you also need to set the *_data variables as side effect.
You can work around the *_data variables, but it will make everything
complicated.
Just untainting variables without verification is a bad idea. One could
argue if there shouldn't be a verifier option for variables instead of
setting the *_data copies, so a single lookup could verify und untaint
two variables, but some check is required. Before I used generic
conditions to verify variables and another condition to match the router,
now I use local_parts and domains, which I never did before. It is about
as readable, once you get used to it.
Michael
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
