Error inviting user: Error sending email #372

New Issue

OVERLORD · 2026-02-04T20:04:21+03:00

OVERLORD commented

2026-02-04 20:04:21 +03:00

Originally created by @d-kholin on GitHub (Aug 12, 2019).

Hey all,

First time poster, so take it easy :)

First, I have to say you guys did a great job on this, love being able to self host my main password manager! However, I have been having some issues with getting the emails for invites to go out. I have a exchange box that I use for my email domain, and have an account setup for Bitwarden to use. In the admin settings, I've setup mail server, username and password, etc, but when I try to send an invite I get "Error inviting user: Error sending email." I couldn't find any logs for Bitwarden, are there any I could look at?

I have Bitwarden behind a reverse proxy, and the reverse proxy has a letsencrypt cert for bitwarden. I saw in another thread https://github.com/dani-garcia/bitwarden_rs/issues/537 that the issue was resolved by setting the Use explicit TLS option, but that hasn't fixed anything for me...

As for my email setup, I followed the guide here: https://github.com/dani-garcia/bitwarden_rs/wiki/SMTP-configuration

Sorry if I'm a little vague, let me know if there is anything else you need from me!

Originally created by @d-kholin on GitHub (Aug 12, 2019). Hey all, First time poster, so take it easy :) First, I have to say you guys did a great job on this, love being able to self host my main password manager! However, I have been having some issues with getting the emails for invites to go out. I have a exchange box that I use for my email domain, and have an account setup for Bitwarden to use. In the admin settings, I've setup mail server, username and password, etc, but when I try to send an invite I get "Error inviting user: Error sending email." I couldn't find any logs for Bitwarden, are there any I could look at? I have Bitwarden behind a reverse proxy, and the reverse proxy has a letsencrypt cert for bitwarden. I saw in another thread https://github.com/dani-garcia/bitwarden_rs/issues/537 that the issue was resolved by setting the Use explicit TLS option, but that hasn't fixed anything for me... As for my email setup, I followed the guide here: https://github.com/dani-garcia/bitwarden_rs/wiki/SMTP-configuration Sorry if I'm a little vague, let me know if there is anything else you need from me!

OVERLORD closed this issue

2026-02-04 20:04:24 +03:00

OVERLORD commented

2026-02-04 20:04:29 +03:00

@dani-garcia commented on GitHub (Aug 15, 2019):

Well the errors we get from the mail library aren't very descriptive, but I'd try double checking that the credentials and the host are correct, and I'd try testing with ports 465 and 587, both with explicit TLS enabled and disabled.

@dani-garcia commented on GitHub (Aug 15, 2019): Well the errors we get from the mail library aren't very descriptive, but I'd try double checking that the credentials and the host are correct, and I'd try testing with ports `465` and `587`, both with explicit TLS enabled and disabled.

OVERLORD commented

2026-02-04 20:04:39 +03:00

@PrivatePuffin commented on GitHub (Jan 30, 2020):

@dani-garcia
can confirm this.

The debug trace:

[2020-01-29 23:12:24][lettre::smtp::client][DEBUG] connecting to [2a01:7c8:e100:                                                                                                                                                                                                                                             1::78e2]:465
[2020-01-29 23:12:24][bitwarden_rs::api::core::accounts][ERROR] Error sending de                                                                                                                                                                                                                                             lete account email: Error sending email. other os error

I find "Connecting to" a bit weird, as I don't have a IPv6 Connection.
However the IPv6 Block does point towards my provider.

I also cant manage to trace the DNS query down the line. Host doesn't do DNS caching by design (which I need to look into because it annoys me, but enfin). All other attempts of calling a domain lead to a 1-to-1 call to the DNS server.

Except this email script, which seem to have its own cache or hidden dns-over-https server or something. Because I don't see a aaaa DNS call anywhere.

And don't think it might get passed, I manually very-carefully firewall block all outgoing port 53 calls and any and all big DNS and dns-over-https providers.

edit

Because we all love tracing things:

[2020-01-29 23:24:05][request][INFO] POST /api/accounts/verify-email
[2020-01-29 23:24:05][lettre::smtp::client][DEBUG] connecting to [2a01:7c8:e100:1::78e2]:465
[2020-01-29 23:24:05][bitwarden_rs::api::core::accounts][ERROR] Error sending delete account email: Error sending email. other os error

It seems somewhere it's getting a aaaa record from and it seems to prefer it over the a record even without any IPv6 connection to the host

edit 2
Because there are two things we like more than more traces: Solutions and Limiting scope of a bug.

Here is the later.
I can limit the scope of this bug by forcefully setting the ipv4 IP in the hosts file of the system. After doing this emails work perfectly fine.

From this research I can conclude that it prefers using a aaaa record over an a record, even when no IPv6 Connection is available.

MOAR
Looking into the codebase, DNS resolution for SMTP send is done by lettre and not by bitwarden_rs directly.
lettre uses std::net::ToSocketAddrs to lookup a dns name.

I don't have a rust development environment to test this, but I expect the mistake sits somewhere between this line in lettre (715c169167/src/smtp/mod.rs (L112)) and rust's way of doing lookups using std::net::ToSocketAddrs

@PrivatePuffin commented on GitHub (Jan 30, 2020): @dani-garcia can confirm this. The debug trace: ``` [2020-01-29 23:12:24][lettre::smtp::client][DEBUG] connecting to [2a01:7c8:e100: 1::78e2]:465 [2020-01-29 23:12:24][bitwarden_rs::api::core::accounts][ERROR] Error sending de lete account email: Error sending email. other os error ``` I find "Connecting to" a bit weird, as I don't have a IPv6 Connection. However the IPv6 Block does point towards my provider. I also cant manage to trace the DNS query down the line. Host doesn't do DNS caching by design (which I need to look into because it annoys me, but enfin). All other attempts of calling a domain lead to a 1-to-1 call to the DNS server. Except this email script, which seem to have its own cache or hidden dns-over-https server or something. Because I don't see a `aaaa` DNS call anywhere. And don't think it might get passed, I manually very-carefully firewall block all outgoing port 53 calls and any and all big DNS and dns-over-https providers. *edit* Because we all love tracing things: > [2020-01-29 23:24:05][request][INFO] POST /api/accounts/verify-email > [2020-01-29 23:24:05][lettre::smtp::client][DEBUG] connecting to [2a01:7c8:e100:1::78e2]:465 > [2020-01-29 23:24:05][bitwarden_rs::api::core::accounts][ERROR] Error sending delete account email: Error sending email. other os error It seems somewhere it's getting a `aaaa` record from and it seems to prefer it over the a record even without any IPv6 connection to the host *edit 2* Because there are two things we like more than more traces: Solutions and Limiting scope of a bug. Here is the later. I can limit the scope of this bug by forcefully setting the ipv4 IP in the hosts file of the system. After doing this emails work perfectly fine. From this research I can conclude that it prefers using a `aaaa` record over an `a` record, even when no IPv6 Connection is available. *MOAR* Looking into the codebase, DNS resolution for SMTP send is done by lettre and not by bitwarden_rs directly. lettre uses std::net::ToSocketAddrs to lookup a dns name. I don't have a rust development environment to test this, but I expect the mistake sits somewhere between this line in lettre (https://github.com/lettre/lettre/blob/715c16916770cbe14b8d8dcb481897582875ce79/src/smtp/mod.rs#L112) and rust's way of doing lookups using std::net::ToSocketAddrs

OVERLORD commented

2026-02-04 20:04:49 +03:00

@PrivatePuffin commented on GitHub (May 2, 2020):

Should be fixed upstream now.
See:
https://github.com/lettre/lettre/issues/391#event-3296774480

So @dani-garcia I think this could be closed.

@PrivatePuffin commented on GitHub (May 2, 2020): Should be fixed upstream now. See: https://github.com/lettre/lettre/issues/391#event-3296774480 So @dani-garcia I think this could be closed.

OVERLORD commented

2026-02-04 20:04:55 +03:00

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

I've updated lettre to the latest master containing that fix, should be built in some hours: 63cbd9ef9c

@dani-garcia commented on GitHub (May 3, 2020): I've updated lettre to the latest master containing that fix, should be built in some hours: https://github.com/dani-garcia/bitwarden_rs/commit/63cbd9ef9c23ff7a13dfbbb7723fbb6ed4c5dc13

OVERLORD referenced this issue

2026-02-05 04:53:16 +03:00

[PR #372] [MERGED] Changed the way to fix the href #2687

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#372