SMTP and debugging problems


First of all, bitwarden_rs is a great piece of software. So, thanks alot!

Now, I cannot get emails to work. I’ve upgraded to the most recent version (master branch, SHA 70f3ab8ec3d6ccfd8ec8c71c888459de484d9b43). I’ve also upgraded the web-vault to the most recent release (v2.12.0e). I’m using the SQLite backend and nginx, if that’s relevant.

E-mails are simply not sent. The web-vault only says “unexpected error”. There is nothing in the logs. I’ve enabled EXTENDED_LOGGING and set LOG_LEVEL=trace. However, I don’t get any messages that relate to emails (lettre crate). I also don’t see any connection attempts in the log files of my postfix installation.

What can I do to debug that further? Do you have an idea why this is not working?


PS: Although I’ve set USE_SYSLOG=false, the logs still appear in the syslog.

Hi there!
Strange that you don’t see any errors, can you check the network tab of the browser developer tools for any failed requests? Particularly the error code and the JSON response if there’s one.

Make sure that the SMTP enabled checkbox is set and that all the values are correct, particularly arround TLS settings and port, which tend to cause issues, then try the test email button from the admin panel once the correct settings are saved.

The syslog feature is enabled when either USE_SYSLOG=true or if you have enabled the ‘enable_syslog’ cargo feature, for backwards compatibility, so make sure you don’t have either of those enabled. If you don’t and you still get syslog output, it might be something else redirecting the logs.

Thanks for your fast reply.

Indeed, I get a 500 (Internal Server Error) status code for the POST request to the server.
So, the code path is probably not triggered on the server side.

If you get a 500 please check the stderr output of bitwarden. If you use docker try ‘docker logs --details -f bitwarden’. There probably is a configuration issue.

Hi BlackDex,

That got me a lot further. bitwarden_rs presented me with this error:

thread '<unnamed>' panicked at 'Failure to parse mechanism. Is it proper Json? Eg. `"Plain"` not `Plain`', src/
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

And, of course, I had


in my .env file (I’m running bitwarden_rs as a systemd unit) as suggested by the .env.template file from the repo. Reading on, I found out that the file is sourced by the shell / process before launching the actual binary. Therefore, I had to escape the quotation marks:


This worked! I now get nice answers to the POST requests. I’ll send a pull request for a correction of the template file soon.

However, mails are still not send. But now I get some log output:

[request][INFO] POST /api/accounts/verify-email
[lettre::smtp::client][DEBUG] connecting to
[lettre::smtp::client][DEBUG] Read: 220 mail.SOMEDOMAIN.TLD ESMTP Postfix<CRLF>
[lettre::smtp][INFO] connection established to
[lettre::smtp::client][DEBUG] Wrote: EHLO mail<CRLF>
[lettre::smtp][DEBUG] server mail.SOMEDOMAIN.TLD with {StartTls, EightBitMime}
[lettre::smtp][INFO] No supported authentication mechanisms available
[lettre::smtp::client][DEBUG] Wrote: MAIL FROM:<bitwarden@SOMEDOMAIN.TLD> BODY=8BITMIME<CRLF>
[lettre::smtp::client][DEBUG] Read: 530 5.7.0 Must issue a STARTTLS command first<CRLF>
[lettre::smtp::client][DEBUG] Wrote: QUIT<CRLF>
[lettre::smtp::client][DEBUG] Read: 221 2.0.0 Bye<CRLF>
[bitwarden_rs::api::core::accounts][ERROR] Error sending delete account email: LetreErr.
[CAUSE] Permanent(
    Response {
        code: Code {
            severity: PermanentNegativeCompletion,
            category: Unspecified3,
            detail: Zero,
        message: [
            "5.7.0 Must issue a STARTTLS command first",
[response][INFO] POST /api/accounts/verify-email (post_verify_email) => 200 OK

It does not matter whether I set SMTP_EXPLICIT_TLS to true or false, I always get the same result.

Why is lettre not establishing a TLS connection? My server will only allow authentication over a secured (i.e., TLS-enabled) connection.


I’ll try changing line 35 from




and will report back.

Works like a charm. (Well, I’ve had to change SMTP_HOST from localhost to the domain in the certificate to have it verified correctly.)
I’ve sent two pull requests.

Thanks for your help debugging the problem!

Hi Sam, can you tell me how to edit I am having the same problem with sending emails since the latest update.

@rstedmond, this is already in the latest version now.
So i guess you have an other issue. What does the log file report about emailing?

I see the following error and I am using standard SMTP access on port 25, no SSL:

[2020-03-19 09:23:06][lettre::smtp][INFO] connection established to
 [2020-03-19 09:23:06][error][ERROR] LetreErr.
 [CAUSE] Io(
     Custom {
         kind: Other,
         error: Failure(
                 Error {
                     code: ErrorCode(
                     cause: Some(
                                     Error {
                                         code: 337047686,
                                         library: "SSL routines",
                                         function: "tls_process_server_certificate",
                                         reason: "certificate verify failed",
                                         file: "../ssl/statem/statem_clnt.c",
                                         line: 1915,
                 X509VerifyResult {
                     code: 64,
                     error: "IP address mismatch",
 [2020-03-19 09:23:06][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request

OK, it looks like when sending email, it is doing a certificate validation check, which I think is not necessary if you are using SMTP port 25. I have updated my email settings to use my host name instead of the IP address, as there is a valid certificate for the host name. Emails are now working correctly.