SMTP E-Mail sending error still reports as success in UI #4187

New Issue

Closed

opened 2026-03-07 19:32:39 -06:00 by GiteaMirror · 11 comments

GiteaMirror commented 2026-03-07 19:32:39 -06:00

Owner

Copy Link

Copy Source

Originally created by @Zauberfisch on GitHub (Jan 1, 2020).

Subject of the issue

When bitwarden_rs tries to send emails via SMTP, not all errors will actually be recognised as errors.

Your environment

• Bitwarden_rs version: 1.13.0

• Install method: arch linux AUR package bitwarden_rs and bitwarden_rs-vault
• Clients used: web vault
• Reverse proxy and version: bitwarden (host A) <> stunnel (v5.56) (host A, self signed cert) <> nginx (v1.16) (host B, letsencrypt cert)
• Version of mysql/postgresql: sqlite
• Other relevant information: external SMTP server

Steps to reproduce

Started through systemd unit file from AUR package

Cause one of the following errors when sending via SMTP:

• connection timeout
• invalid TLS handshake (presumably that was a protocol/port missmatch)
• invalid credentials

Expected behaviour

UI should tell the user that sending an email failed

Actual behaviour

Green notification pops up saying it was sent

Relevant logs

Jan 01 00:22:39 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:39][_][INFO] Matched: POST /api/accounts/verify-email (post_verify_email)
Jan 01 00:22:39 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:39][lettre::smtp::client][DEBUG] connecting to 10.20.30.40:465
Jan 01 00:22:54 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:54][bitwarden_rs::api::core::accounts][ERROR] Error sending delete account email: Error sending email. connection timed out
Jan 01 00:22:54 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:54][_][INFO] Outcome: Success

Originally created by @Zauberfisch on GitHub (Jan 1, 2020). <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unneccessary for your issue, feel free to remove them. Remember to hide/obfuscate personal and confidential information, such as names, global IP/DNS adresses and especially passwords, if neccessary. --> ### Subject of the issue When bitwarden_rs tries to send emails via SMTP, not all errors will actually be recognised as errors. ### Your environment <!-- The version number, obtained from the logs or the admin page --> * Bitwarden_rs version: 1.13.0 <!-- How the server was installed: Docker image / package / built from source --> * Install method: arch linux AUR package `bitwarden_rs` and `bitwarden_rs-vault` * Clients used: web vault<!-- if applicable --> * Reverse proxy and version: bitwarden (host A) <> stunnel (v5.56) (host A, self signed cert) <> nginx (v1.16) (host B, letsencrypt cert) * Version of mysql/postgresql: sqlite<!-- if applicable --> * Other relevant information: external SMTP server ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start bitwarden_rs? --> Started through systemd unit file from AUR package Cause one of the following errors when sending via SMTP: * connection timeout * invalid TLS handshake (presumably that was a protocol/port missmatch) * invalid credentials ### Expected behaviour UI should tell the user that sending an email failed ### Actual behaviour Green notification pops up saying it was sent ### Relevant logs <!-- Share some logfiles, screenshots or output of relevant programs with us. --> ``` Jan 01 00:22:39 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:39][_][INFO] Matched: POST /api/accounts/verify-email (post_verify_email) Jan 01 00:22:39 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:39][lettre::smtp::client][DEBUG] connecting to 10.20.30.40:465 Jan 01 00:22:54 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:54][bitwarden_rs::api::core::accounts][ERROR] Error sending delete account email: Error sending email. connection timed out Jan 01 00:22:54 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:54][_][INFO] Outcome: Success ```

GiteaMirror added the troubleshooting label 2026-03-07 19:32:39 -06:00

GiteaMirror closed this issue 2026-03-07 19:32:39 -06:00

GiteaMirror commented 2026-03-07 19:32:40 -06:00

Author

Owner

Copy Link

Copy Source

@Crow-Control commented on GitHub (Jan 29, 2020):

I can confirm and limit the error scope somewhat:
When doing an invite from the organisation screen this does give the right error.
When doing a email verification from the user homescreen, it gives a screen "everything okey", even when failing.

@Crow-Control commented on GitHub (Jan 29, 2020): I can confirm and limit the error scope somewhat: When doing an invite from the organisation screen this does give the right error. When doing a email verification from the user homescreen, it gives a screen "everything okey", even when failing.

GiteaMirror commented 2026-03-07 19:32:40 -06:00

Author

Owner

Copy Link

Copy Source

@sekdiy commented on GitHub (May 13, 2020):

I can confirm that this is still relevant and also affects the Test SMTP (Send test email) functionality in the admin panel.

I just caused an authentication error, but all tests were reported successful.

@sekdiy commented on GitHub (May 13, 2020): I can confirm that this is still relevant and also affects the `Test SMTP` (`Send test email`) functionality in the admin panel. I just caused an authentication error, but all tests were reported successful.

GiteaMirror commented 2026-03-07 19:32:41 -06:00

Author

Owner

Copy Link

Copy Source

@dani-garcia commented on GitHub (May 13, 2020):

The server always returns errors when it gets them, but some client endpoints don't handle them and they always show success, there's not much we can do about those as they probably aren't related to bitwarden_rs.

That said, if this happens in the admin panel we should be handling them correctly, @sekdiy can you check the network requests tab in your browser to see what response you get from the /admin/test/smtp/ endpoint?

@dani-garcia commented on GitHub (May 13, 2020): The server always returns errors when it gets them, but some client endpoints don't handle them and they always show success, there's not much we can do about those as they probably aren't related to bitwarden_rs. That said, if this happens in the admin panel we should be handling them correctly, @sekdiy can you check the network requests tab in your browser to see what response you get from the /admin/test/smtp/ endpoint?

GiteaMirror commented 2026-03-07 19:32:43 -06:00

Author

Owner

Copy Link

Copy Source

@Zauberfisch commented on GitHub (May 14, 2020):

@dani-garcia I think this is in fact a bitwarden_rs issue.

In the log file I posted, the last line says:

Jan 01 00:22:54 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:54][_][INFO] Outcome: Success

The Outcome: Success leads me to believe this is wrongly handled on the server

When I click on "Verify Email -> Send Email" on a new Account, the HTTP Response is an empty body with the following headers:

HTTP/1.1 200 OK
Server: Rocket
Feature-Policy: accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'none'; sync-xhr 'self' https://haveibeenpwned.com https://twofactorauth.org; usb 'none'; vr 'none'
Referrer-Policy: same-origin
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Security-Policy: frame-ancestors 'self' chrome-extension://nngceckbapebfimnlniiiahkandclblb moz-extension://*;
Cache-Control: no-cache, no-store, max-age=0
Access-Control-Allow-Origin: https://bitwarden.my-domain.com
Content-Length: 0
Date: Thu, 14 May 2020 12:21:07 GMT

@Zauberfisch commented on GitHub (May 14, 2020): @dani-garcia I think this is in fact a bitwarden_rs issue. In the log file I posted, the last line says: ``` Jan 01 00:22:54 bitwarden.my-domain.com bitwarden_rs[633]: [2020-01-01 00:22:54][_][INFO] Outcome: Success ``` The `Outcome: Success` leads me to believe this is wrongly handled on the server When I click on "Verify Email -> Send Email" on a new Account, the HTTP Response is an empty body with the following headers: ``` HTTP/1.1 200 OK Server: Rocket Feature-Policy: accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; picture-in-picture 'none'; sync-xhr 'self' https://haveibeenpwned.com https://twofactorauth.org; usb 'none'; vr 'none' Referrer-Policy: same-origin X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Content-Security-Policy: frame-ancestors 'self' chrome-extension://nngceckbapebfimnlniiiahkandclblb moz-extension://*; Cache-Control: no-cache, no-store, max-age=0 Access-Control-Allow-Origin: https://bitwarden.my-domain.com Content-Length: 0 Date: Thu, 14 May 2020 12:21:07 GMT ```

GiteaMirror commented 2026-03-07 19:32:45 -06:00

Author

Owner

Copy Link

Copy Source

@Crow-Control commented on GitHub (May 14, 2020):

I agree with @Zauberfisch I also saw the success originating from bitwarden_rs in the logs when I looked into this.

@Crow-Control commented on GitHub (May 14, 2020): I agree with @Zauberfisch I also saw the success originating from bitwarden_rs in the logs when I looked into this.

GiteaMirror commented 2026-03-07 19:32:47 -06:00

Author

Owner

Copy Link

Copy Source

@BlackDex commented on GitHub (Oct 5, 2020):

There have been a lot changes done to the email library since the last comment here.
If this still is an issue please give some more details.

@BlackDex commented on GitHub (Oct 5, 2020): There have been a lot changes done to the email library since the last comment here. If this still is an issue please give some more details.

GiteaMirror commented 2026-03-07 19:32:47 -06:00

Author

Owner

Copy Link

Copy Source

@l0rem commented on GitHub (Oct 10, 2020):

1.16.3 as of today - the issue is still there.

@l0rem commented on GitHub (Oct 10, 2020): 1.16.3 as of today - the issue is still there.

GiteaMirror commented 2026-03-07 19:32:47 -06:00

Author

Owner

Copy Link

Copy Source

@BlackDex commented on GitHub (Oct 12, 2020):

@l0rem Could you give us an example maybe, which steps to reproduce this, and what message do you get in the logs?

@BlackDex commented on GitHub (Oct 12, 2020): @l0rem Could you give us an example maybe, which steps to reproduce this, and what message do you get in the logs?

GiteaMirror commented 2026-03-07 19:32:48 -06:00

Author

Owner

Copy Link

Copy Source

@BlackDex commented on GitHub (Nov 18, 2020):

@Zauberfisch, @l0rem and @sekdiy Have you tried v1.17.0 already?
That version includes a lot of changes to handling emails and has some better error reporting.
And does it still produce any error.

Also, i just have create a new PR #1229 which could help in trying to debug this issue.
We have to wait for this PR to be merged for you to test (unless you build it your self).

@BlackDex commented on GitHub (Nov 18, 2020): @Zauberfisch, @l0rem and @sekdiy Have you tried v1.17.0 already? That version includes a lot of changes to handling emails and has some better error reporting. And does it still produce any error. Also, i just have create a new PR #1229 which could help in trying to debug this issue. We have to wait for this PR to be merged for you to test (unless you build it your self).

GiteaMirror commented 2026-03-07 19:32:48 -06:00

Author

Owner

Copy Link

Copy Source

@BlackDex commented on GitHub (Nov 18, 2020):

As of today there is a new testing version available on docker hub which has among an updated mail library, also an SMTP_DEBUG option available. Maybe this could help i troubleshooting this issue.

@BlackDex commented on GitHub (Nov 18, 2020): As of today there is a new `testing` version available on docker hub which has among an updated mail library, also an SMTP_DEBUG option available. Maybe this could help i troubleshooting this issue.

GiteaMirror commented 2026-03-07 19:32:48 -06:00

Author

Owner

Copy Link

Copy Source

@BlackDex commented on GitHub (Dec 12, 2020):

Going to close this one because of inactivity and there have been some more changes done including the SMTP_DEBUG option.
If this issue still is unsolvable using that feature please feel free to re-open this ticket.

@BlackDex commented on GitHub (Dec 12, 2020): Going to close this one because of inactivity and there have been some more changes done including the `SMTP_DEBUG` option. If this issue still is unsolvable using that feature please feel free to re-open this ticket.

GiteaMirror referenced this issue 2026-04-20 14:03:47 -05:00

[GH-ISSUE #4187] Not starting after updating #10623

GiteaMirror referenced this issue 2026-04-23 06:20:44 -05:00

[GH-ISSUE #4187] Not starting after updating #14600

GiteaMirror referenced this issue 2026-04-25 20:45:08 -05:00

[GH-ISSUE #4187] Not starting after updating #18584

GiteaMirror referenced this issue 2026-06-17 08:52:49 -05:00

[GH-ISSUE #4187] Not starting after updating #29302

GiteaMirror referenced this issue 2026-07-13 19:28:49 -05:00

[GH-ISSUE #4187] Not starting after updating #34762

GiteaMirror referenced this issue 2026-07-17 10:13:39 -05:00

[GH-ISSUE #4187] Not starting after updating #39055

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

v2-registration

revert-7033-patch-1

cached-config-operations

test_dylint

1.37.2

1.37.1

1.37.0

1.36.0

1.35.8

1.35.7

1.35.6

1.35.5

1.35.4

1.35.3

1.35.2

1.35.1

1.35.0

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

Labels

Clear labels

better for forum

bug

documentation

duplicate

enhancement

future Vault

good first issue

help wanted

low priority

notes

pull-request

Mirrored from GitHub Pull Request

question

SSO

Third party

troubleshooting

wontfix

No labels troubleshooting

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

GiteaMirror ninjasurge (Kaehlen Rog)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#4187