Author: Michael Haardt Date: To: Jeremy Harris via Exim-users Subject: Re: [exim] Exim 4.94.0.4 works where Exim 4.94 fails with tainted
path 'not permitted'
Jeremy Harris via Exim-users <exim-users@???> wrote: > On 08/11/2020 14:47, Michael Haardt via Exim-users wrote:
> > In the old days, that was the standard way of matching. Then conditions
> > were added, many people switched to them, and now we go back to the old
> > domains/local_parts way, because that sets the *_data variables.
> >
> > If the documentation stated that somehow, it would ease migrations.
> Suggestions for (wording and where to put it) welcome.
The generic discussion how a router works sounds like a good place
to me for giving a hint on the intended usage. Here is an idea:
Chapter 3, section 12: Router preconditions
Append to "domains":
A match verifies the tainted variable $domain and assigns it to the
untainted variable $domain_data. It is recommended to use this option
instead of the generic condition option, which does not set untainted
variables and is run after all other options.
Append to "local_parts":
A match verifies the tainted variable $local_part and assigns it to the
untainted variable $local_part_data. It is recommended to use this
option instead of the generic condition option, which does not set
untainted variables and is run after all other options.
Append to "condition":
This option is meant to be used for final checks, not for matching
the recipient address, because it cannot verify the tainted variables
$local_part and $domain, even if they are used in a lookup. While it
technically works to use this option for address matching, most likely
either a previously checked option or the transport needs access to
the verified local part and domain, and avoiding those accesses is more
complicated than using the domains and local_parts options for address
matching that setup the verified variables.
