Exim customized configs: suggestion

1

Obviously if you’re editing your own system configs then you have assumed responsibility for keeping them up to date. Personally I’ve made several modifications to exim configs over the years, to install rspamd, to change various limits for clients who send a lot of emails, to enhance SSL config on more up to date clients, and so on.

As we’ve just been through some fairly major changes to the behaviour of exim with the latest 1.6 updates, if you’ve made customizations, I would urge you to download the latest base config from github, here

and use a diff tool to make sure your configs are all up to date. I’ve just done this on a few servers, and found a few differences, ranging from small formatting differences, and rearrangement of blocks, to some fairly serious changes.

Examples:

  1. I’d previously made some changes to re-write spam headers using a file called system_filter. This is now superceded in some configs by the file system.filter added by Hestia devs.
  2. When the recent rate-limit problems were occuring, I rolled back my config to a previous 1.5 version. However when I did that, the changes in 1.6.2 weren’t properly applied, so I had to manually add the new rate limit stanzas.

There may be more examples. I take full responsibility for the changes I make to my own servers, and any breakage that ensues. If you’re like me, now is a good time to go through exim configs and make sure they’re all up to date.

2

Ideally we need to go to a “better” method of detecting custom changes have been made. But with all the customisations is is so complicated…

If you have any idea how to achieve it please share them :slight_smile:

3

I can’t really think of one immediately, and, in fact, this is what stopped my attempts to write an automated spamasssassin to rspamd conversion script. Its a tough problem.

I guess there would be some value in separating various configs out into included files. For eg SSL config could go in one file, ACLs in another, etc. Then each file could be tested with md5sum. But also there is downside to having config separated like that.

Maybe even putting Section headers and placeholder text in the single config file would be an intermediate step. You could quite easily extract the code between two known headers and do an md5sum on that. Just thinking out loud …

ansible seems quite good at processing config files. Maybe I’ll see if that could help.

1 Like