On 30/8/24 18:57, altoid via Dng wrote:
> Hello:
>
> On 30 Aug 2024 at 16:52, Brad Campbell via Dng wrote:
>
>> ... exim broke in non-obvious ways ...
> Quite so.
>
> But you are not alone.
> Been there, suffered the consequences and dealt with the fallout.
>
>> ... entirely non-obvious and poorly documented.
> To say the least.
>
> Although I beg to differ on *poorly*, which I consider to be a huge
> understatement. 8^/

I must say the deeper I dig, the more I think the Exim maintainers kinda dropped the ball on this one. It almost feels like a work in progress pushed out to quickly patch some holes.

> If interested, here is a recount of what I went through when this
> mess affected my workstation three years ago:
>
> https://dev1galaxy.org/viewtopic.php?pid=30412#p30412

A fairly basic issue, but yeah if you're not into Exim it would have been a bit of a bear/pig to figure out and moreso solving it when you have no idea how it got into that state.

> After I understood what had happened, I reported the problem (with as
> much detail as possible) as a bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990344

An interesting take. I can see the package maintainers perspective. Config files are checksummed so dpkg can tell if they've been altered. It's a neat feature we rely on when staging and scripting upgrades and it's usually very reliable. Having said that, nothing is 100% and it seems you got stung.

> Do have a look.
> Makes for *very* interesting reading.
> Particularly on how to waste time doing such a thing.
>

It's interesting because I upgraded 7 physical machines and 6 VMs this week and I don't recall seeing the news entry in any of the changelogs.

If it makes you feel any better, I've got > 28 years of linux under my belt and been working on mail systems since Sendmail. It still took me the best part of 5 hours to locate, diagnose and rectify.

Here we use Exim to front other mail systems, so ~21 domains with 17 local and 4 directed to other servers (Zimbra or Exchange for example). The config isn't particularly complex (there's probably 40 lines across 3 additional config files in /etc/exim/conf.d (split config FTW), but when it breaks there's usually more than 2 pieces to re-assemble.
To be fair, this particular incarnation is probably 14 years old now and this is the first major breakage on an upgrade. We have a fully replicated test system but the upgrade tests missed this issue. More unit tests to write :)

I agree on the basic desktop MTA. Because we have a pair of full fat MTAs here, almost every other machine (desktop, server or VM) runs ssmtp or msmtp. It's basically a conduit straight to the real MTA.

Regards,
Brad