Marc's Blog: computers - i386 to amd64 to arm64 for Raspberry Pi5 upgrade, part 2: Exim4 made this very painful: Lack of insecure_tainted_data option, untaintable local_parts, no untaint() function, and magic local_part

This is part #2 of

Finishing Upgrade of Year 2000 Linux System From i386 to amd64 to arm64 for Raspberry Pi5 with mailman 2.1.7 for Python 2 (the last 5% that took 70% of the time)

as an upgrade for

Magic v5: From Dell Poweredge 2950 to Raspberry Pi 5 (skipping Dell DSS1510)

After upgrading my main server from amd64 to arm64 (rPi), I was forced to re-install all of linux, first time in 25+ years for that server, which included upgrading every single linux package I had t o Debian/Trixie (13). Those upgrades are always "interesting" when you have a lot of history and state, but turns out it went pretty well, except for exim4.

As much as I'm thankful for exim4 and its developers, and all the work they do, I respecfully think the way they implemented tainting on $local_part, the name of the recipient, was poor and with no regard to the cost of countless admins whose configs got broken. Namely:

Debian literally had to write allow_insecure_tainted to avoid breaking their users overnight. They knew how bad the upgrade and breakage were going to be (sadly it was removed later and exim4 didn't use the hint to lessen the pain of upgrades)

Exim never provided a clear guide on the most common ways to fix this, including clear fixes for common configurations, using mailman with exim being one of them. Exim has an excellent documentation that is very extensive, but takes days to read and understand (it was over a week my first time 25 years ago). Expecting users to dig back into such a complex system many years later and figure out very non trivial config steps, is not fair in my book.

why is there no detailled message in exim panic_log to tell the admin what happened and what to do, along with a bounce message saying the answer is in local exim logs?

add a untaint() with fixed safe regex that will work for most everyone

the local_part_data is deep black magic and not a reasonable sole solution (it's empty and unusable by default). There should be a local_part_safe that is automatically populated via a safe regex

the debian answer of "turn off tainting" should honestly be a real option. Forcing admins to be broken if they have certified they are safe, or in an environment where it's really fine, is NOT an appropriate answer and honestly unfair to admins who deal with lots of things and, cannot be experts on deep internals of dozens or hundreds of daemons. Yes, that means allowing an admin who may already have been running an unsafe setup for 20 years, to potentially continue to do so if they deem it's actually ok/safe in in their setup. The admin must be trusted and not treated like a clueless person that must be blocked from running the software (breaking delivery to mailman is blocking me from using exim altogether).

For people who disagree with that last point, please understand that it is still there no matter what. If admins cannot untaint a safe config, they will downgrade exim, and it looks like I did exactly that in the past. This is literally the worst case scenario users are forced into if they can't figure out a very non trivial solution with very few clues

Exim posts:

https://lists.exim.org/lurker/message/20251027.164803.8ab41844.en.html

https://lists.exim.org/lurker/message/20251027.162524.1f7d6cf1.en.html

https://lists.exim.org/lurker/message/20251027.181509.83258145.en.html

So here is what I figured out in the end, after way too many hours (probably more than 10h at this point, which is totally not cool, uprades should not cause downtimes of 10h plus that amount of lost admin time in debugging, research, and fixing): Exim seems to have totally over-reacted to the local_part untrusted data problem, given literally no way to the admin to clean up the variable on their own with a safe regex, maybe provided by exim itself, and seems to force the admin to compare local_part against trusted data on the server only, or it will simply remain tainted and unusable. This is way over the top, especially when you can run a command in pipe without suffering from shell quoting issues.

The solution I found after help from others, is:

mm21_director:
  debug_print = "R: mm21_director for $local_part@$domain"
  driver = accept
  # black magic to populate local_part_data, the untainted version of local_part
  local_parts = dsearch,filter=dir;MAILMAN_HOME/lists
  require_files = MAILMAN_HOME/lists/${lc::$local_part_data}/config.pck
  local_part_suffix = "-bounces:-bounces+*:-confirm+*:-join:-leave:-owner:-request:-admin"
  transport = mm21_transport
.endif

mm21_transport:
  debug_print = "T: mm21_transport for $local_part@$domain"
  driver = pipe
  # In case you wonder, substr_2 removes the leading '-'
  # and the regex removes optional +foo=hostname that can be after -bounce
  # (if you use VERP) -- Marc
  command = MAILMAN_WRAP "${if def:local_part_suffix{${substr_2:{${sg{${lc:$local_part_suffix}}{\\\\\+.*}{}}}}{post}}"
${lc:$local_part_data}
  current_directory = MAILMAN_HOME
  home_directory = MAILMAN_HOME
  user = MAILMAN_UID
  group = MAILMAN_GID

What I had to fix is add "local_parts = dsearch,filter=dir;MAILMAN_HOME/lists" which was 100% required for local_part_data to be populated. Without that, local_part_data is and remains NULL.
It's disappointing how non trivial and over complicated this is, and most importantly how there was no "MUST READ THIS TAINTED UPGRADE" document with proper detailled info around this in one place (not scattered around a very big manual), along with the most common solutions to the very extreme new tainted restrictions.

Useful links I saved along the way:

https://postmaster.google.com/u/5/dashboards#do=merlins.org&st=inboundDeliveryErrorRate&dr=7

https://mxtoolbox.com/SuperTool.aspx?action=dkim%3amerlins.org%3a20251023&run=toolpage

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-dkim_spf_srs_and_dmarc.html