Exim's change to 'taint' some Exim variables is going to cause us pain
Exim is a very flexible mail system (aka a MTA, Mail Transfer agent), to the extent that in its raw state Exim is a mailer construction kit more than a mailer (if you want a simple mailer, consider Postfix). You can use this power for a lot of things, like building simple mailing lists, where a mailing list is created by putting a file of addresses in a specific directory (the name of the file being the name of the mailing list).
This flexibility and power can create security issues, for example when you directly use information from the incoming mail message (information that's under the control of the sender) to open a file in a directory. If not carefully controlled, an attacker who knows enough about your Exim configuration could possibly make you open files you don't intend to, like '../../../etc/passwd'.
(This is a standard risk when using information that's ultimately provided by an attacker.)
For a long time, Exim left it up to whoever wrote your Exim configuration file to worry about this. It was on them to do input validation to make sure that /cs/lists/$local_part would never have anything dangerous in it. Recently the Exim developers decided that this was not sufficient and introduced the idea of 'tainted data', which isn't allowed to be used in various places (especially, as part of a filename that will be opened or accessed). Things that are under the control of a potential attacker, such as the local part or the domain of an address, are tainted.
Unfortunately, there are a lot of places where it's traditionally
been natural to use the Exim
$local_part string variable as
part of file access, which is now tainted and forbidden. Specifically,
we have various places in the Exim configurations for several mail
machines that use it. These uses are safe in our environment because
we only make use of
$local_part after it's been verified to
exist in our generated list of valid local addresses, but Exim isn't
smart enough to know that they're safe. Instead there are a collection
of ways to de-taint strings (eg,
which from one perspective are a set of artificial hoops you now
have to jump through to pacify Exim. Some of these options for
de-tainting are backward compatible to versions of Exim before
tainting was introduced, but generally the compatible ways are more
awkward than the modern best ways.
People, us included, who upgrade to a version of Exim that includes tainting will have to go through their Exim configuration files and revise them to de-taint various things the configuration needs to use. For us, this has to happen for any upgrade of our mail machines to Ubuntu 20.04; 20.04 has a version of Exim with tainting, while the Exim versions in 18.04 and 16.04 are pre-tainting ones. This means that upgrading any of our mail machines to Ubuntu 20.04 needs configuration changes, and some of these configuration changes may not be backward compatible. I think I can find all of the places where our Exim configurations might use tainted data, but I'm not completely confident of that; if I miss one, we're going to experience Exim errors and failures to properly process some email in production.
This is going to be a little bit painful. I'm not looking forward to it, especially as it is yet another case of 'do more work to wind up in exactly the same place'.
(There's an obvious better way for the Exim people to have done this transition to tainted data, but it would have been slower and meant that Exim remained insecure by default for longer.)
PS: We're at least better off than the people on CentOS using EPEL, who apparently got a 'tainted data' version of Exim just dropped on them as a regular package update (cf).