I don't know what "tainting" means and an English dictionary lookup
didn't make it more plausible. But as you're referring to the
'quote_pgsql' function I guess you mean escaping of SQL query
parameters. This certainly does not cause issues here because the local
part is "demo" or "demo2" in this case, and this concept certainly isn't
new either (I used quote_mysql in my Ubuntu 16.04 setup) and absolutely
required since the invention of SQL queries.
Also, modifying the Sieve text does have an effect and at least once
also forwards the message to the address specified in the script. So the
filter must be accessible. It's just not interpreted by Exim in the
expected way.
-Yves
-------- Ursprüngliche Nachricht --------
Von: Andrew C Aitchison via Exim-users <exim-users@???>
Gesendet: Mittwoch, 7. Oktober 2020, 16:02 MESZ
Betreff: [exim] Sieve filter not working properly anymore, how to debug?
On Wed, 7 Oct 2020, Yves Goergen via Exim-users wrote:
Hello,
I'm setting up a new mail server with Exim and try to get the Sieve filter
working as it does on another server. But it doesn't. And I don't know why.
The Exim version is 4.93 on Ubuntu Linux 20.04.
This is a part of my Exim config. All addresses with maildirs and sieve data
is stored in a database.
SQL_FILTER = \
select E'# Sieve filter\n' || sieve_filter \
from mail_entries \
where local = '${quote_pgsql:$local_part}' and domain =
'${quote_pgsql:$domain}' and maildir <> '' and sieve_filter <> ''
The mainlog doesn't show more than the in and out events. There are
especially no errors. (I can have errors when I leave out the Sieve filter
comment prefix or use an invalid database query or break the database
permissions. I've seen all of this but they're fixed and the messages are
gone.)
How can I debug or fix the Sieve filter in Exim? I thought that the config I
have here is about the same as what's already working with the Exim from
Ubuntu 16.04.
A new concept "Tainting" was introduced to exim between Ubuntu 16.04 and
20.04.
quote_pgsql may untaint $local_part (I am not familiar with quote_pgsql),
but in many configurations $local_part causes taintedness and failures;
the fix in some cases is to replace it with $local_part_data *and* ensure
that the router does check_local_user.
