[GH-ISSUE #940] "500 - Internal Server Error" when sending test mail #665

New issue

Closed

opened 2026-03-03 02:01:57 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 02:01:57 +03:00

Owner

Originally created by @maeries on GitHub (Mar 31, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/940

Subject of the issue

I set up bitwarden_rs to use google mail to send out emails. When I send the test mail I get a popup saying:

Error sending SMTP test email
500 - Internal Server Error

Your environment

Bitwarden_rs version: 1.14.1-5471088e
Install method: Downloaded from docker hub. Run using docker-compose
Reverse proxy and version: none
Other relevant information: Installed on a ubuntu server VM (KVM on Proxmox). Had a similar problem running on a ubuntu LXC container #924, so I installed bitwarden_rs on a VM to see if that helps

Steps to reproduce

Install like described above
Configure the mail settings like this

(checking "Use explicit TLS" and using port 587 gives the same error)
Click "send test mail"

Expected behaviour

Send a Mail to the given address

Actual behaviour

Popup shown up, giving a error message and no mail is received

Relevant logs

bitwarden_1  | [2020-03-31 09:39:13][panic][ERROR] thread 'unnamed' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Custom { kind: Other, error: "failed to lookup address information: Name or service not known" })': src/mail.rs:40
bitwarden_1  |    0: bitwarden_rs::init_logging::{{closure}}
bitwarden_1  |    1: std::panicking::rust_panic_with_hook
bitwarden_1  |              at src/libstd/panicking.rs:474
bitwarden_1  |    2: rust_begin_unwind
bitwarden_1  |              at src/libstd/panicking.rs:378
bitwarden_1  |    3: core::panicking::panic_fmt
bitwarden_1  |              at src/libcore/panicking.rs:85
bitwarden_1  |    4: core::option::expect_none_failed
bitwarden_1  |              at src/libcore/option.rs:1211
bitwarden_1  |    5: bitwarden_rs::mail::send_email
bitwarden_1  |    6: bitwarden_rs::mail::send_test
bitwarden_1  |    7: bitwarden_rs::api::admin::rocket_route_fn_test_smtp
bitwarden_1  |    8: <F as rocket::handler::Handler>::handle
bitwarden_1  |    9: rocket::rocket::Rocket::route_and_process
bitwarden_1  |   10: <rocket::rocket::Rocket as hyper::server::Handler>::handle
bitwarden_1  |   11: hyper::server::Worker<H>::handle_connection
bitwarden_1  |   12: hyper::server::listener::spawn_with::{{closure}}
bitwarden_1  |   13: std::sys_common::backtrace::__rust_begin_short_backtrace
bitwarden_1  |   14: std::panicking::try::do_call
bitwarden_1  |   15: __rust_maybe_catch_panic
bitwarden_1  |              at src/libpanic_unwind/lib.rs:86
bitwarden_1  |   16: core::ops::function::FnOnce::call_once{{vtable.shim}}
bitwarden_1  |   17: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
bitwarden_1  |              at rustc/564758c4c329e89722454dd2fbb35f1ac0b8b47c/src/liballoc/boxed.rs:1017
bitwarden_1  |   18: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
bitwarden_1  |              at rustc/564758c4c329e89722454dd2fbb35f1ac0b8b47c/src/liballoc/boxed.rs:1017
bitwarden_1  |       std::sys_common::thread::start_thread
bitwarden_1  |              at src/libstd/sys_common/thread.rs:13
bitwarden_1  |       std::sys::unix::thread::Thread::new::thread_start
bitwarden_1  |              at src/libstd/sys/unix/thread.rs:80
bitwarden_1  |   19: start_thread
bitwarden_1  |   20: clone

Originally created by @maeries on GitHub (Mar 31, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/940 ### Subject of the issue I set up bitwarden_rs to use google mail to send out emails. When I send the test mail I get a popup saying: > Error sending SMTP test email > 500 - Internal Server Error ### Your environment * Bitwarden_rs version: 1.14.1-5471088e * Install method: Downloaded from docker hub. Run using docker-compose * Reverse proxy and version: none * Other relevant information: Installed on a ubuntu server VM (KVM on Proxmox). Had a similar problem running on a ubuntu LXC container #924, so I installed bitwarden_rs on a VM to see if that helps ### Steps to reproduce 1. Install like described above 2. Configure the mail settings like this ![bitwarden fehler](https://user-images.githubusercontent.com/30597531/78023140-6a898300-7356-11ea-8f90-0ef045468dd1.png) (checking "Use explicit TLS" and using port 587 gives the same error) 3. Click "send test mail" ### Expected behaviour Send a Mail to the given address ### Actual behaviour Popup shown up, giving a error message and no mail is received ### Relevant logs ``` bitwarden_1 | [2020-03-31 09:39:13][panic][ERROR] thread 'unnamed' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Custom { kind: Other, error: "failed to lookup address information: Name or service not known" })': src/mail.rs:40 bitwarden_1 | 0: bitwarden_rs::init_logging::{{closure}} bitwarden_1 | 1: std::panicking::rust_panic_with_hook bitwarden_1 | at src/libstd/panicking.rs:474 bitwarden_1 | 2: rust_begin_unwind bitwarden_1 | at src/libstd/panicking.rs:378 bitwarden_1 | 3: core::panicking::panic_fmt bitwarden_1 | at src/libcore/panicking.rs:85 bitwarden_1 | 4: core::option::expect_none_failed bitwarden_1 | at src/libcore/option.rs:1211 bitwarden_1 | 5: bitwarden_rs::mail::send_email bitwarden_1 | 6: bitwarden_rs::mail::send_test bitwarden_1 | 7: bitwarden_rs::api::admin::rocket_route_fn_test_smtp bitwarden_1 | 8: <F as rocket::handler::Handler>::handle bitwarden_1 | 9: rocket::rocket::Rocket::route_and_process bitwarden_1 | 10: <rocket::rocket::Rocket as hyper::server::Handler>::handle bitwarden_1 | 11: hyper::server::Worker<H>::handle_connection bitwarden_1 | 12: hyper::server::listener::spawn_with::{{closure}} bitwarden_1 | 13: std::sys_common::backtrace::__rust_begin_short_backtrace bitwarden_1 | 14: std::panicking::try::do_call bitwarden_1 | 15: __rust_maybe_catch_panic bitwarden_1 | at src/libpanic_unwind/lib.rs:86 bitwarden_1 | 16: core::ops::function::FnOnce::call_once{{vtable.shim}} bitwarden_1 | 17: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once bitwarden_1 | at rustc/564758c4c329e89722454dd2fbb35f1ac0b8b47c/src/liballoc/boxed.rs:1017 bitwarden_1 | 18: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once bitwarden_1 | at rustc/564758c4c329e89722454dd2fbb35f1ac0b8b47c/src/liballoc/boxed.rs:1017 bitwarden_1 | std::sys_common::thread::start_thread bitwarden_1 | at src/libstd/sys_common/thread.rs:13 bitwarden_1 | std::sys::unix::thread::Thread::new::thread_start bitwarden_1 | at src/libstd/sys/unix/thread.rs:80 bitwarden_1 | 19: start_thread bitwarden_1 | 20: clone ```

kerem closed this issue

2026-03-03 02:01:57 +03:00

kerem commented

2026-03-03 02:01:58 +03:00

Author

Owner

@BlackDex commented on GitHub (Mar 31, 2020):

It seems the dns resolving does not work.
Maybe something on the host, or within the docker container the resolving isn't working.

@BlackDex commented on GitHub (Mar 31, 2020): It seems the dns resolving does not work. Maybe something on the host, or within the docker container the resolving isn't working.

kerem commented

2026-03-03 02:01:58 +03:00

Author

Owner

@BlackDex commented on GitHub (Mar 31, 2020):

Also, try the commands here: https://github.com/dani-garcia/bitwarden_rs/issues/688#issuecomment-551076546

@BlackDex commented on GitHub (Mar 31, 2020): Also, try the commands here: https://github.com/dani-garcia/bitwarden_rs/issues/688#issuecomment-551076546

kerem commented

2026-03-03 02:01:58 +03:00

Author

Owner

@maeries commented on GitHub (Apr 1, 2020):

nevermind. For some reason I had the host set to smtp.google.com. Don't ask me how that happend. After setting it to smtp.gmail.com like I had in the screenshot, I get the LetreErr that I posted in #924. So you were right that DNS resolving was the problem

@maeries commented on GitHub (Apr 1, 2020): nevermind. For some reason I had the host set to smtp.google.com. Don't ask me how that happend. After setting it to smtp.gmail.com like I had in the screenshot, I get the LetreErr that I posted in #924. So you were right that DNS resolving was the problem