Dovecot 2.4 bug with Thunderbird

[Panormitis]

DirectAdmin Developers
Please see:

Thunderbird and Dovecot 2.4.0 Incompatibility - dovecot - dovecot.org

dovecot.org

1968384 - BAD Error in IMAP command APPEND: Missing ')'

RESOLVED (nobody) in MailNews Core - Networking: IMAP. Last updated 2025-05-27.

bugzilla.mozilla.org

I'm using Thunderbird and I think I'm experiencing that bug. Once I set mail.imap.use_literal_plus to false, in Thunderbird, everything works normally.

Since the fix is already included: https://github.com/dovecot/core/com...12df6e0eed634aa4fe92c225b54ef5ee965b35c.patch
I believe Dovecot should be recompiled using the latest source files.

 

[Panormitis]

It seems my issue was different. I'm using Thunderbird and from time to time I wasn't receiving mail at startup nor I could save mail to Sent of imap accounts. Most times I could restart Thunderbird and the issue was going away for a while until it resurface randomly again. However all these started occurring when I upgraded to Dovecot 2.4, so I was primarily suspecting Dovecot, not Thunderbird.
So I investigated further:

In /var/log/dovecot-lmtp-errors.log there were some erros such as: "lmtp(4085101): Error: conn unix:/run/dovecot/anvil (pid=3904345,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied".
lmtp runs as mail:mail but /run/dovecot/anvil had root:root ownership.

So I did the following:

cd /usr/local/directadmin/custombuild
mkdir -p custom/dovecot/2.4/conf
cp configure/dovecot/2.4/conf/service.conf custom/dovecot/2.4/conf
cd custom/dovecot/2.4/conf

Edit service.conf and add:
service anvil {
  unix_listener anvil {
    group = mail
    mode = 0660
  }
}

Then, execute:
da build dovecot_conf
systemctl restart dovecot

/run/dovecot/anvil should have root:mail ownership now. Permission denied errors are gone and Thunderbird seems to behave correctly.

 

[Richard G]

lmtp runs as mail:mail but /run/dovecot/anvil had root:root ownership.

Oeps... seems this is indeed wrongly done. I got the same errors in my log:

Error: conn unix:/run/dovecot/anvil (pid=961,uid=0): net_connect_unix(/run/dovecot/anvil) failed: Permission denied

Unfortunately I don't have an older server running older Dovecot to see what permissions were before.

However, how do you know lmtp is running as mail?
In my case it's running as user or as root.

root       69857  0.0  0.0  16332 11264 ?        S    00:52   0:00  \_ dovecot/lmtp
startva+  123901  0.0  0.0  22404 15232 ?        S    01:05   0:00  \_ dovecot/lmtp [local READY]

However, the lmtp.conf says mail.

# LMTP socket for local delivery from exim
service lmtp {
  executable = lmtp -L
  process_min_avail = 16
  unix_listener lmtp {
    user = mail
    group = mail
    mode = 0660
  }
}

Is that something DA needs fixing @fln?

 

[Panormitis]

Hi Richard. I have the same lmtp.conf, it says user = mail & group = mail so it's running with mail:mail ownership.

# ls -l /run/dovecot/lmtp
srw-rw---- 1 mail mail 0 Aug 20 22:15 /run/dovecot/lmtp

Check how anvil is running via: ls -l /run/dovecot/anvil
If it's root:root, my workaround changes it to root:mail and fixes the permission denied errors.

 

[Richard G]

If it's root:root, my workaround changes it to root:mail and fixes the permission denied errors.

Yes as I stated it is running as root. You're workaround would indeed work, but that's a workaround. I'm interested in a final fix and so wondering if that is a fix DA would need to do or Dovecot needs to do.

 

[fln]

The socket /run/dovecot/lmtp is used by the Exim process to deliver emails. Because Exim is running as mail the socket should be accessible to the mail UNIX user.



The lmtp process runs as root user and should have no problems connecting to the anvil socket. We need to be able to reproduce the problem to investigate further.

 

[Richard G]

Thank you for the explanation.
I have them regularly, though not many in the error log, but I don't know what could be causing them.

Maybe @Panormitis knows a way to reproduce them?

 

[Panormitis]

The socket /run/dovecot/lmtp is used by the Exim process to deliver emails. Because Exim is running as mail the socket should be accessible to the mail UNIX user.



The lmtp process runs as root user and should have no problems connecting to the anvil socket. We need to be able to reproduce the problem to investigate further.

Ok understood, but why the Anvil socket had root:root ownership which causes permission denied errors between them? I don't see any benefit from that behavior, I see Permission Denied errors which are not occurring now.

 

[Panormitis]

Thank you for the explanation.
I have them regularly, though not many in the error log, but I don't know what could be causing them.

Maybe @Panormitis knows a way to reproduce them?

If I remove the customization I did in service.conf, Permission Denied errors reappear since /run/dovecot/anvil would have root:root ownership again. I can easily reproduce it like that.

 

[fln]

@Panormitis, please open a support ticket so we could check the situation on your server. What specific action starts failing when you have removed the customization? I mean sending an email over SMTP, or some specific action over IMAP?

 

[Panormitis]

@fln I started investigating because ever since I upgraded to Dovecot 2.4, I had problems with Thunderbird on Imap accounts.
Thunderbird would not receive messages at startup or it would send a message correctly but not copy it to the Sent folder. The only remedy was to kill it (killall thunderbird) and then it would work correctly.
It could have been a Thunderbird client issue and not a Dovecot issue, perhaps. But I started digging and found the Permission Denied errors.
After applying my workaround, Thunderbird issues were gone, but that could be a coincidence. I don't have definite proof that my Thunderbird issues are fixed because of it, since I couldn't locate the definite source of the problem. All I remember is having issues after I upgraded to Dovecot 2.4.

However, since Permission Denied errors were occurring, changing ownership fixes them. I doubt Permission Denied errors are harmless.