starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 01:35:54 +03:00
Code Issues 39 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #791] SMTP E-Mail sending error still reports as success in UI #548

New issue
Closed
opened 2026-03-03 01:30:26 +03:00 by kerem · 11 comments
kerem commented 2026-03-03 01:30:26 +03:00
Owner
Copy link

Originally created by @Zauberfisch on GitHub (Jan 1, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/791

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). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/791 <!-- 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 ```
kerem 2026-03-03 01:30:26 +03:00
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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.

<!-- gh-comment-id:579992959 --> @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.
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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.

<!-- gh-comment-id:628089426 --> @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.
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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?

<!-- gh-comment-id:628262587 --> @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?
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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
<!-- gh-comment-id:628599800 --> @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 ```
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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.

<!-- gh-comment-id:628674868 --> @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.
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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.

<!-- gh-comment-id:703862403 --> @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.
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

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

1.16.3 as of today - the issue is still there.

<!-- gh-comment-id:706614179 --> @l0rem commented on GitHub (Oct 10, 2020): 1.16.3 as of today - the issue is still there.
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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?

<!-- gh-comment-id:707287876 --> @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?
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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).

<!-- gh-comment-id:729643020 --> @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).
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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.

<!-- gh-comment-id:730016593 --> @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.
kerem commented 2026-03-03 01:30:27 +03:00
Author
Owner
Copy link

@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.

<!-- gh-comment-id:743781036 --> @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.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
revert-7033-patch-1
cached-config-operations
test_dylint
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   
SSO

   
Third party

   
better for forum

   
bug

   
bug

   
documentation

   
duplicate

   
enhancement

   
future Vault

   
future Vault

   
future Vault

   
good first issue

   
help wanted

   
low priority

   
notes

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
troubleshooting

   
wontfix
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#548
No description provided.