Re: Making pglister work with exim 4.96+

> Yeah, and I don't see why they would? The reason they do the taint marking in variables used in commands and filenames is that it would be a potential venue for attackers to inject things. No such vulnerability exists with environment variables. Obviously the receiving code, whether a shellscript or a python program or a c program or whatever, can have injection vulnerabilities of it's own, but the passing values layer (which is what Exim is responsible for there) does not.

Yet this is what we want to do here: bypass security protection by passing dangerous data through environment variables. It would make sense for them to prevent that usage

> Yeah, this seems extremely fragile. Concurrent delivery is a common thing, and not the only potential problem I bet. The proper fix surely is to make invoke.py work properly.

What's invoke.py? Do you mean inject.py?

I'm aware of the potential concurrency issues. One fix could be to only process emails in mailqueuehandler.py if their sender address is not empty (or we could add a boolean field for that purpose).

> And the above doesn't actually solve the problem does it? It still requires passing the message-id which is a tainted variable?

$message_id is not the header, it's exim's internal message ID and is untainted.
Here's my current version, handling the header as well:
event_action = ${if eq {msg:delivery}{$event_name} {${lookup pgsql{update incoming_mail set sender='${quote_pgsql:$sender_address}', messageid='${quote_pgsql:$header_message-id:}' where messageid='${quote_pgsql:$message_id}'; notify incoming; update bounce_mail set sender='${quote_pgsql:$sender_address}', messageid='${quote_pgsql:$header_message-id:}' where messageid='${quote_pgsql:$message_id}'; notify bounce}} {}}}

Another overall solution may be to fetch header_message-id and sender_address from exim in inject.py using a subprocess (provided it's still queued at that point?)

--
Célestin Matte