I’m using Kmail 6.8.1 with Proton Mail, which requires Proton Mail Bridge, an app that exposes a local IMAP server.
On startup I get an alert from “IMAP E-Mail Server” saying:
The IMAP server for account Proton refused the supplied username and password.
Do you want to try again, or open the settings?
Login failed, server replied: A000004 NO no such user
Since this does not repeat during the session, I’m assuming the connection is attempted before Proton Mail Bridge is ready.
My questions are:
is “IMAP E-Mail Server” Akonadi? (if not, who?)
can I prevent it from connecting on startup, and do it only when I run Kmail?
yeah that “no such user” once at boot is almost always Akonadi hitting Bridge before Bridge finished starting.
the disconnect-on-close setting wont help that race. what usually works for me:
1. make Proton Mail Bridge start on login (autostart)
2. delay Akonadi a bit, or restart the resource after Bridge is up:
`systemctl --user restart akonadi`
if you want it automatic, a tiny user systemd drop-in that runs `akonadictl restart` a few seconds after Bridge has been used to clear that first popup for me. you can also ignore the one-shot dialog if mail works the rest of the session. not great UX but it is a startup ordering thing more than bad credentials.
Better 2 : Make the systemd user session manage the Proton bridge, and add a “Before=akonadi_control” directive to the Proton Bridge unit.
Restarting Akonadi “randomly” after 30s is just asking for more randomness.
Also please report this to Proton Bridge. It should have a user unit (preferrably with the “Before” directive included), and it definitely shouldn’t return “no such user” while starting up.
After learning a bit about systemd units, I removed the Proton Mail Bridge autostart and enabled this systemd user unit I wrote:
~/.config/systemd/user/protonmail-bridge.service
[Unit]
Description=Proton Mail Bridge (IMAP/SMTP bridge for Proton Mail)
Documentation=https://proton.me/mail/bridge
# Make sure Bridge is fully started before Akonadi initializes its mail resources
Before=akonadi_control.service
After=graphical-session.target
PartOf=graphical-session.target
[Service]
Type=simple
ExecStart=/usr/bin/protonmail-bridge --no-window
Restart=on-failure
RestartSec=5
[Install]
WantedBy=default.target
It appears to be working as expected, no more errors on startup.
Still, I wish I could tell Akonadi there’s no need to rush with IMAP servers.
Maybe it has no effect on Akonadi startup only, before Kmail is even started.
Actually, in that same dropdown you mentioned, there’s a “Check mail on startup” option (which was already off for me). I would have thought it mattered in this case, but I assume it’s strictly for Kmail and is not passed to Akonadi.
I also was unsure about that. I asked an LLM (Proton’s Lumo specifically) to explain various unit clauses, and it thinks “it only launches once your desktop session exists”.
Please note --no-window was the autostart option and it launches the graphical app, it just keeps the window closed. There is the --noninteractive option that I wanted to go with, but the process eventually terminated with some gRPC issue that I still need to investigate.
That’s correct. It probably needs the session to exist. It seems to be a Qt GUI program, and that requires loading the correct platform, for that the session needs to exist.. --noninteractive might change it into a non-gui program. Unless you’re curious and have fun doing it, leave it be…
Yeah I’m somewhat curious, 'cause I feel the --noninteractive mode is how the Bridge should work.
On a disappointing note, I just rebooted my machine and got the error message again. Now I need to learn how to debug systemd to understand why Akonadi was too early. First guess, when the ExecStart target returns it moves on to the next (Akonadi), but that doesn’t mean that the Bridge account is available yet.