[SOLVED] Exim4 error messages

Altoid · 2021-06-20 13:00:33

Hello:

I'm getting these mails in my user account:

Subject: exim paniclog on devuan has non-zero size
To: root@devuan
Message-Id: <E1lsebV-000146-0x@devuan>
From: root <root@devuan>
Date: Mon, 14 Jun 2021 01:53:41 -0300
Status: O

exim paniclog /var/log/exim4/paniclog on devuan has non-zero size, mail system might be broken. Up to 10 lines are quoted below.

2021-06-13 21:21:49 1lsAUd-0001xc-6C == groucho@devuan R=local_user T=mail_spool defer (-1): Tainted '/var/mail/groucho' (file or directory name for mail_spool transport) not permitted
--- snip ---
2021-06-14 01:33:33 1lsX5B-00024J-0o == groucho@devuan R=local_user T=mail_spool defer (-1): Tainted '/var/mail/groucho' (file or directory name for mail_spool transport) not permitted

These messages do exist in /var/log/exim4/paniclog but I cannot find out what is going on.
I've had other paniclog entries but these were caused by the IPv6 entries in the hosts file, which I then commented:

groucho@devuan:~$ cat /etc/hosts
127.0.0.1        devuan                localhost

#::1              localhost            ip6-localhost ip6-loopback
#fe00::0          ip6-localnet
#fe00::0          ip6-mcastprefix
#fe02::1          ip6-allnodes
#fe02::1          ip6-allrouters
groucho@devuan:~$

My user is in both the mail and the debian-exim groups:

groucho@devuan:~$ groups
groucho adm lp mail dialout fax cdrom floppy tape sudo audio dip www-data backup video plugdev staff users crontab netdev lpadmin scanner saned fuse powerdev debian-exim
groucho@devuan:~$

/var/mail/groucho belongs to my user and the mail group:

groucho@devuan:~$ ls -l /var/mail/groucho
-rw-rw---- 1 groucho mail 20337 Jun 20 09:01 /var/mail/groucho
groucho@devuan:~$

Exim version is 4.94.2:

groucho@devuan:/var/mail$ sudo exim --version
Exim version 4.94.2 #2 built 26-May-2021 15:52:52
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC Event I18N OCSP PIPE_CONNECT PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
groucho@devuan:/var/mail$

I found these links from 2020 that discuss/address the problem:

https://www.mail-archive.com/exim-users … 54868.html
https://www.mail-archive.com/exim-users … 54870.html
https://www.mail-archive.com/exim-users … 54875.html

From the comments it would seem that the developers have not been up to par with the update to 4.94.2 and a lot of admins are not happy.
But it's 06/2021 and things (apparently) remain the same. (?)

I really don't want to break anything in my installation because of the MTA so I'd be quite willing to roll back to the previous exim4 version.

Which would be the safest way to go about doing that?
Or is there another way to avoid all the de-tainting hassle with the chance of breaking something?

Edit:

Looking around for the exim4 configuration files, I finally found /var/lib/exim4/config.autogenerated which starts like this:

groucho@devuan:~$ cat /var/lib/exim4/config.autogenerated
#########
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# This file was generated dynamically from
# non-split config (/etc/exim4/exim4.conf.localmacros
# and /etc/exim4/exim4.conf.template).
# The config files are supplemented with package installation/configuration
# settings managed by debconf. This data is stored in
# /etc/exim4/update-exim4.conf.conf
# Any changes you make here will be lost.
# See /usr/share/doc/exim4-base/README.Debian.gz and update-exim4.conf(8)
# for instructions of customization.
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
#########

So I went to /etc/exim4/update-exim4.conf.conf, which would be the conf file for exim4:

groucho@devuan:~$ cat /etc/exim4/update-exim4.conf.conf
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes   # is it just me or does
# to this file might happen. The code handling this will honor your local     # anyone else read this 
# changes, so this is usually fine, but will break local schemes that mess    # as devspeak for "screw
# around with multiple versions of the file.                                  # you, you are on your own"?
#
# update-exim4.conf uses this file to determine variable values to generate      
# exim configuration macros for the configuration file.
#                       
# Most settings found in here do have corresponding questions in the          # !!!!
# Debconf configuration, but not all of them.                                 # !!!!
#
# This is a Debian specific file

dc_eximconfig_configtype='local'
dc_other_hostnames='groucho'
dc_local_interfaces='127.0.0.1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
groucho@devuan:~$

[rant]
Who's in charge of exim4, Poettering?
[/rant]

Edit 2:

Interesting and well written post, only understood between 50% and 75% of it. 8^/
But the first two paragraphs are very revealing of what has happened with exim.

See: https://lists.exim.org/lurker/message/2 … 4d.en.html

Thanks in advance,

A.

Last edited by Altoid (2021-06-20 14:05:26)

dice · 2021-06-20 14:12:12

Ive never had to roll back a package on debian before but i dont believe it is straightforward process.

See here: https://vincent.bernat.ch/en/blog/2020-downgrade-debian

Be aware that link downgrades all packages so just change the * to the package you want downgraded.

Alternatively give sendmail a try?

https://tecadmin.net/install-sendmail-o … 10-buster/

Altoid · 2021-06-20 21:28:00

Hello:

dice wrote:

... never had to roll back a package ...
... dont believe it is straightforward process.

Never done it either.
I have pinned a package which may (?) be more or less the same idea.

An MTA is essential for any Linux installation, the mails I get (when I remember to look ...) have brought me up to date with respect to issues I had with crontab, backups, trim, etc.

Can't do without one.

Exim had some security issues with vulnerabilities discovered early this year and this last version tightened things up a bit.
But, from what I have read, it seems changes were not rolled out in a proper manner and even veteran admins are at odds as to how to get things done with the new version.

I've read at least one post that characterises sendmail as not easy to deal with citing "... complicated configuration steps and demands, and weak security mechanisms ...", something I really don't need.

What I want to know is how to deal with this #%&@ tainting problem so that exim4 can keep doing what it was doing before the same way it was doing it: silently and efficiently.

Seems I'm in a spot: if experienced professional admins* can't understand how to ge that done, what can I expect to achieve?

Thanks for your input.

Best,

A.

* See the links in my OP.

Edit: spelling, etc.

Last edited by Altoid (2021-06-21 02:29:51)

Altoid · 2021-06-21 12:28:50

Hello:

Altoid wrote:

... how to deal with this #%&@ tainting problem so that exim4 can keep doing what it was doing ...

I think I have found a solution.
I say think because I don't have a clue as to how all this works.
ie: if this is just a workaround or a proper configuration option.

If it is just a workaround the new security schemes in exim4, then it is bound to be temporary and we'll have to be alert.
If it is a proper configuration option, WTF is it not properly documented somewhere?

I found it here:
https://www.linuxquestions.org/question … ost6136422

In this case, the problem seems to be that exim4 now does not like the directory name for my mail folder.
I think it has to do with the backlashes in /var/mail/username.

It would be really nice if whoever came up with this (must be necessary, they know how it all works) just wrote up a small bit or a proper comment inside this file informing that the solution was to edit the file /etc/exim4/exim4.conf.template which is used for the most basic exim4 configuration.
ie: the non-split configuration scheme I expect is used by most of us here at Dev1.

Evidently too much to ask. 8^/

To the point:

The part of this huge 2122 line configuration file that must be edited is the one concerning mail spool configuration.

#####################################################
 ### transport/30_exim4-config_mail_spool
 #####################################################
 
 ### transport/30_exim4-config_mail_spool
 
 # This transport is used for local delivery to user mailboxes in traditional
 # BSD mailbox format.
 #
 mail_spool:
   debug_print = "T: appendfile for $local_part@$domain"
   driver = appendfile
   file = /var/mail/$local_part # <----- this is the line that has to be edited 
   delivery_date_add
   envelope_to_add
   return_path_add
   group = mail
   mode = 0660
   mode_fail_narrower = false
 
 #####################################################
 ### end transport/30_exim4-config_mail_spool
 #####################################################

It seems that the line file = /var/mail/$local_part has to be edited to read file = /var/mail/$local_part_data.

Sort of makes me wonder if there is any reason for the edited line not being there by default.

Caveat emptor:
I have not tested this yet, the post where I got it had a following one saying that it works.

----> EDIT
For this to work properly the exim4 configuration has to be updated.
BTW: did you see anything about it in the comments at the start of the exim4.conf.template file?
No?
I thought as much ...

As root run:

[root@devuan groucho]# update-exim4.conf -v
using non-split configuration scheme from /etc/exim4/exim4.conf.template
[root@devuan groucho]# jed /etc/exim4/exim4.conf.template

/EDIT <----

I'll post back in a couple of days reboots with the results.

Best,

A.

Last edited by Altoid (2021-06-22 11:40:52)

Altoid · 2021-06-21 13:05:43

Hello:

Altoid wrote:

... post back in a couple of days reboots with the results.

Apparently it works* as expected. 8^)

Edit:
See the edit in my previous post.
The exim4 needs to be updated, otherwise modifications to the template file are not incorporated to the rest of the configuration files.

The script update-exim4.conf generates the main configuration files /var/lib/exim4/config.autogenerated for Exim v4 by merging the data in the template file
/etc/exim4/exim4.conf.template or the ones in the /etc/exim4/conf.d directory tree respectively and /etc/exim4/update-exim4.conf.conf to the output file /var/lib/exim4/config.autogenerated.

On reboot my mailbox received notice of a number of notifications (crontab and such for logfiles) that had been delayed for as much as 144 hours.
Which means that exim4 no longer has an issue with /var/mail/username.

Clearing the mailbox and rebooting showed no mail in my mailbox.

So that's that.

Best,

A.

Last edited by Altoid (2021-06-22 11:45:55)

Altoid · 2021-06-22 11:03:59

Hello:

Altoid wrote:

Apparently it works as expected. 8^)

It just dawned on me that the solution I linked to comes from the OP comparing his exim.conf with another file called exim.conf.rpmnew.
Very smart.

This other configuration file is included in a distribution (manjaro?) that detected the problem created by the exim4 update and edited the original file accordingly.

The new (exim.conf.rpmnew) file had the "file" listed as: file = /var/mail/$local_part_data

Maybe the Devuan/Debian (or better yet, the exim4 packagers may want to consider doing the same with the /etc/exim4/exim4.conf.template file.

Q: should a bug report be filed somewhere?

Best,

A.

Last edited by Altoid (2021-06-22 11:16:53)

Altoid · 2021-06-23 13:25:37

Hello:

Altoid wrote:

Apparently it works* as expected. 8^)

Much to my chagrin, no.
It does not. 8^|

I am still getting the same error:

2021-06-21 09:04:47 1lrnn0-000275-6X == groucho@devuan R=local_user T=mail_spool defer (-1): Tainted '/var/mail/groucho' (file or directory name for mail_spool transport) not permitted

ie: mail is being generated, held back and not delivered to my mailbox at /var/mail/groucho because exim4 does not like it anymore.

Unfortunately, editing the exim4/conf/template file as previously described does not solve the problem which apparently needs a deeper editing of the template to get rid of all the offending variables.

https://git.exim.org/exim.git/blob/HEAD … E.UPDATING

README.UPDATING wrote:

Exim version 4.94
-----------------
Some Transports now refuse to use tainted data in constructing their delivery
location; this WILL BREAK configurations which are not updated accordingly.
In particular: any Transport use of $local_part which has been relying upon
check_local_user far away in the Router to make it safe, should be updated to
replace $local_part with $local_part_data.
Attempting to remove, in router or transport, a header name that ends with
an asterisk (which is a standards-legal name) will now result in all headers
named starting with the string before the asterisk being removed. We recommend
staying away from such names, if they are private ones (and in case of future
enhancements, also header names that look like REs).

I found this on the web from a chap who explains what's going on and shows (warning against using it) an unsafe solution to the problem.

Here's another chap who explains the different errors, their causes and possible solutions.

All of which is very nice, these chap's efforts are commendable but don't show a workable path for the Linux desktop user.

exim4 is the default MTA for Devuan/Debian.
And it's default configuration ie: non-split configuration scheme which uses the /etc/exim4/exim4.conf.template file is the one probably used by 99% of all Devuan/Debian desktops.

The result of the upgrade to exim4 4.94.2 (without an updated /etc/exim4/exim4.conf.template file) is a broken default MTA in Devuan/Debian.
ie: a MTA that does not transport mail and to that effect is useless.

Is there a solution to this that does not involve a crash course in exim4 configuration?

The configuration file is 2121 lines long which I expect is rather out of reach (at least it is for me) to appropiately edit and fix, something I think exim4 developers should have done.

So I'm at a loss as to what to do now.
And cannot but wonder if I am the only one affected by this problem here at Dev1 as I have not seen any posts about exim error messages.

Maybe it is time to roll back to the previous exim4 version and risk it?

Comments welcome.

Best,

A.

Last edited by Altoid (2021-06-23 13:27:47)

Altoid · 2021-06-24 01:06:41

Hello:

Altoid wrote:

Comments welcome.

One at a time, please, there's room for everyone ...

I think that the problem may lie in the fact that (according to apt) the installed exim4 configuration package ie: exim4-config is not the same version as the rest of the exim4 files in the stable-backports repository:

groucho@devuan:~$ apt list | grep installed | grep exim4

exim4-base/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]  # <---  | X |    
exim4-daemon-light/stable-backports,now 4.94.2-5~bpo10+1 amd64 [installed,automatic]
exim4/stable-backports,stable-backports,now 4.94.2-5~bpo10+1 all [installed]
groucho@devuan:~$

All files are 4.94.2-5~bpo10+1 with the exception of exim4-config which is 4.92-8+deb10u6.

It does not seem to be available:

groucho@devuan:~$ apt list | grep exim4-config
exim4-config/stable,stable,stable-security,stable-security,now 4.92-8+deb10u6 all [installed,automatic]
groucho@devuan:~$

[root@devuan groucho]# apt install exim4-config
Reading package lists... Done
Building dependency tree       
Reading state information... Done
exim4-config is already the newest version (4.92-8+deb10u6).
exim4-config set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan groucho]#

The strange thing is that version 4.94.2-5~bpo10+1 is available in http://deb.devuan.org/merged beowulf-backports/main which is in my sources.list file.

groucho@devuan:~$ cat /etc/apt/sources.list
## package repositories
# Changed - 20210218 - upgrade to Beowulf

# beowulf stable
deb http://deb.devuan.org/merged/ beowulf main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-security main contrib non-free 
deb http://deb.devuan.org/merged/ beowulf-updates main contrib non-free 

# needed x virtualbox backport - enable to update package
deb http://deb.devuan.org/merged/ beowulf-backports non-free contrib main  

# virtual box repository x installation
# deb http://download.virtualbox.org/virtualbox/debian/ buster non-free contrib 
groucho@devuan:~$

Could anyone explain what's going on with my sources.list?

Thanks in advance,

A.

Altoid · 2021-06-25 14:45:52

Hello:

Altoid wrote:

... what's going on with my sources.list?

UPDATE
I was finally able to get to the bottom of all this exim4 hassle.

Please bear with me, I'll try to be as brief as possible.

When a number of important security failures (dubbed 21 Nails by the IT press) were discovered in exim4 earlier this year, the maintainers were very fast on their feet and an upgraded version 4.94.2 was released almost right away, albeit not without some uproar from the community as this new fixed version actually broke a lot of things for many a sysadmin, things that had been working perfectly well for years.

To the extent that a great many considered opting to downgrade or write risky workarounds.
I have written about this in previous posts, read and check the links if you need more info.

Bottom line?

exim 4.94.2 effectively broke any and all configurations that had been set up with previous versions, whether they used the default configuration ie: the non-split configuration scheme which uses the /etc/exim4/exim4.conf.template file or the split configuration scheme used in more complex installations and which you can eventually opt for when installing Devuan or by running dpkg-reconfigure exim4-config later on.

As a result, from stand alone desktops to production environments to server farms, absolutely everyone updating to exim 4.94.2 was affected.

As mentioned, the default non-split configuration scheme, probably used by 99% of all Devuan/Debian desktops, uses the /etc/exim4/exim4.conf.template which is part of the exim-config package, in turn a dependency of the exim-base package.

The problem I have been bitching about all this time was generated when I updated to exim 4.94.2, something I expected to be a straightforward affaire, without any hassles.

And as (most) any other update, it was.

Half way through, the installer popped up a warning in my terminal informing me that the configuration file being installed ie: the previously mentioned exim4.conf.template was different to the one I had in place and prompted me to choose what to do:

1. keep the installed configuration (default)
2. install the new configuration
3. check and compare the differences.

I chose the default option and in doing so broke my exim4 installation.

As a result my Devuan Beowulf ceased to have a working MTA, all system mail was being held back.
ie: not delivered to my /var/mail/user folder while /var/log/exim4/paniclog slowly grew in size.

I found out about the cause of all this rather by accident.
After not being able to find a solution and fed up with looking, I decided to downgrade exim4 to the previous version and just risk it.

Then, looking at the installed packages, I noticed a discrepancy in their versions ie: exim-config had the previous package version number.

I downloaded and installed the proper version and when the installer warning described above popped up in my terminal, I realised what had happened when I upgraded to 4.94.2.

exim4 is now working as before.

----

Now, after feeling like an idiot for a whole afternoon, I asked myself:

1.
Why would I not choose the default option offered by the installer?

After all, WTF do I know about exim4?
Save that it is the default MTA in Devuan and it keeps me informed as to what is going on via the system mails I get in my /var/mail/user folder, nothing much.

I am not running a mail server from my box and if I add another box to my ADSL router, I believe sending mails between the two boxes is a simple affaire.

Like probably 99% of the Devuan desktops out there, a working default MTA is all I need.

In any case and just like the people who run them, I am just an average user and as such have an inherent trust in everything I download and install from the Devuan repositories, so I had absolutely no reason to choose anything but the default option recommended by the installer.

If I did not have this trust, my box would have something else running inside.

2.
Taking into account that exim 4.94.2 breaks all configurations set up with previous versions of the package ...

rant --->
How is it possible that the exim 4.94.2 installer offers me (as the default and recommended option, no less) to keep a configuration file that, belonging to a previous version, will effectively break it and make it useless?
<--- /rant

From https://www.exim.org/docs.html

exim.org wrote:

All versions of Exim previous to version 4.94.2 are now obsolete.

From https://git.exim.org/exim.git/blob/HEAD … E.UPDATING

Exim version 4.94
-----------------
Some Transports now refuse to use tainted data in constructing their delivery\nlocation; this WILL BREAK configurations which are not updated accordingly. In particular: any Transport use of $local_part which has been relying upon\ncheck_local_user far away in the Router to make it safe, should be updated to replace $local_part with $local_part_data.

The /etc/exim4/exim4.conf.template file has 2200 lines of code contains a number of $local_part and check_local_user bits.
Unfortunately, editing it by hand did not help me when I did it, so evidently something else was needed.

That's about it.

Best,

A.

Last edited by Altoid (2021-06-30 12:05:53)

Altoid · 2021-06-30 00:56:30

Hello:

Altoid wrote:

That's about it.

Sort of ...

For some reason I decided it would be of use to file a bug against exim 4.94.2.
If interested you can read all about it here.

tl;tr:
It seems that it is not a bug if you update a package, chose the default and recommended action offered by the dpkg installer and as a result break an essential part of your Linux system.

If you (as you absolutely *should* have) updated to exim 4.94.2, check your system mail to see if it is working as expected

Cheers,

A.

Last edited by Altoid (2021-06-30 01:01:03)

The officially official Devuan Forum!

#1 2021-06-20 13:00:33

[SOLVED] Exim4 error messages

#2 2021-06-20 14:12:12

Re: [SOLVED] Exim4 error messages

#3 2021-06-20 21:28:00

Re: [SOLVED] Exim4 error messages

#4 2021-06-21 12:28:50

Re: [SOLVED] Exim4 error messages

#5 2021-06-21 13:05:43

Re: [SOLVED] Exim4 error messages

#6 2021-06-22 11:03:59

Re: [SOLVED] Exim4 error messages

#7 2021-06-23 13:25:37

Re: [SOLVED] Exim4 error messages

#8 2021-06-24 01:06:41

Re: [SOLVED] Exim4 error messages

#9 2021-06-25 14:45:52

Re: [SOLVED] Exim4 error messages

#10 2021-06-30 00:56:30

Re: [SOLVED] Exim4 error messages

Board footer