[GH-ISSUE #4528] Panic if temporary SMTP-Problem #1910

New issue

Closed

opened 2026-03-03 02:13:19 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 02:13:19 +03:00

Owner

Originally created by @Subito on GitHub (Apr 29, 2024).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4528

Subject of the issue

Sometimes on trying to send a 2FA-Mail, the SMTP Server replies with 454: 4.7.0 Temporary authentication failure, which should indicate to the sender "please try later, this is a temporary problem". However vaultwarden panics if it receives this error and the server stops.

Deployment environment

vaultwarden version: 1.30.3

Install method: FreeBSD pkg
Clients used: happens on all clients on Login
Reverse proxy and version: nginx
Other relevant details:

Expected behaviour

Server does not crash if it receives a temporary SMTP-Failure.

Actual behaviour

Server crashes and needs restarting.

Troubleshooting data

Apr 29 16:13:58 vault1 vaultwarden[66287]: [2024-04-29 16:13:58.251][vaultwarden::mail][ERROR] SMTP 4xx error: transient error (454): 4.7.0 Temporary authentication failure: Connection lost to authentication server
Apr 29 16:13:58 vault1 vaultwarden[66287]: [2024-04-29 16:13:58.252][panic][ERROR] thread 'tokio-runtime-worker' panicked at 'Error sending incomplete 2FA email: SMTP 4xx error: transient error (454): 4.7.0 Temporary authentication failure: Connection lost to authentication server': src/api/core/two_factor/mod.rs:273

Originally created by @Subito on GitHub (Apr 29, 2024). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4528   ### Subject of the issue  Sometimes on trying to send a 2FA-Mail, the SMTP Server replies with `454: 4.7.0 Temporary authentication failure`, which should indicate to the sender "please try later, this is a temporary problem". However vaultwarden panics if it receives this error and the server stops. ### Deployment environment     * vaultwarden version: 1.30.3  * Install method: FreeBSD pkg * Clients used: happens on all clients on Login  * Reverse proxy and version: nginx  * Other relevant details: ### Expected behaviour  Server does not crash if it receives a temporary SMTP-Failure. ### Actual behaviour  Server crashes and needs restarting. ### Troubleshooting data ``` Apr 29 16:13:58 vault1 vaultwarden[66287]: [2024-04-29 16:13:58.251][vaultwarden::mail][ERROR] SMTP 4xx error: transient error (454): 4.7.0 Temporary authentication failure: Connection lost to authentication server Apr 29 16:13:58 vault1 vaultwarden[66287]: [2024-04-29 16:13:58.252][panic][ERROR] thread 'tokio-runtime-worker' panicked at 'Error sending incomplete 2FA email: SMTP 4xx error: transient error (454): 4.7.0 Temporary authentication failure: Connection lost to authentication server': src/api/core/two_factor/mod.rs:273 ```

kerem

2026-03-03 02:13:19 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-03 02:13:20 +03:00

Author

Owner

@BlackDex commented on GitHub (Apr 29, 2024):

Vaultwarden does not have a retry mechanisch for these kind of scenarios. The message indicates a connection error.

Most of the time temp errors should be tried again after a few minutes, but this is not something Vaultwarden handles. I also do not thing Vaultwarden should handle those and try again actually. That kind of functionality belongs to mail servers, not clients.

We probably can catch this error and return an error instead of a panic though, that is probably nicer then a panic.

@BlackDex commented on GitHub (Apr 29, 2024): Vaultwarden does not have a retry mechanisch for these kind of scenarios. The message indicates a connection error. Most of the time temp errors should be tried again after a few minutes, but this is not something Vaultwarden handles. I also do not thing Vaultwarden should handle those and try again actually. That kind of functionality belongs to mail servers, not clients. We probably can catch this error and return an error instead of a panic though, that is probably nicer then a panic.

kerem commented

2026-03-03 02:13:20 +03:00

Author

Owner

@Subito commented on GitHub (Apr 30, 2024):

Of course, just catching the error would be great. As you said: Any sort of queue-and-retry should be handled on a mailserver. But panicing on a simple SMTP-Error is probably not great. Just logging an error would be perfect.

@Subito commented on GitHub (Apr 30, 2024): Of course, just catching the error would be great. As you said: Any sort of queue-and-retry should be handled on a mailserver. But panicing on a simple SMTP-Error is probably not great. Just logging an error would be perfect.