[GH-ISSUE #1037] SMTP stopped working after Docker tag 2020626 #9545

New Issue

GiteaMirror · 2026-04-20T12:42:46-05:00

GiteaMirror commented

2026-04-20 12:42:46 -05:00

Originally created by @RainmakerRaw on GitHub (Jun 26, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1037

Subject of the issue

I run Synology Docker with bitwardenrs. My SMTP provider is iCloud, and the settings work fine (emails are successfully delivered, testing in the Admin page works). As soon as I upgrade the container from 2020626 to latest, emails no longer deliver. There are 'smtp error', 400 errors, and complaints about a self-signed certificate in the chain. If I revert back to 2020626 (same Docker config file, same settings, same data dir etc) things work fine again and I can send mail perfectly.

Your environment

Bitwarden_rs version: 1.15.1-b34d5482

Install method: Synology Docker using bitwardenrs/server:latest
Clients used:
Reverse proxy and version:
Version of mysql/postgresql:
Other relevant information:

Steps to reproduce

The container is launched with the following SMTP settings for iCloud (which work in 2020626):

Host: smtp.mail.me.com
Enable SSL: true
Explicit TLS: false
Port: 587
From address: My iCloud email address
From name: Bitwarden_RS
Username: My iCloud email address
Password: My secret password
Json form auth mechanism: (blank)
SMTP connection timeout: 15

Expected behaviour

A test email delivered to my own address should be sent and deliver successfully.

Actual behaviour

SMTP error.

The logs include 400 errors, and a complaint that there's a self-signed cert in the chain (this is Apple, and it doesn't complain on the older version. Other apps send mail just fine also).

As I said above, moving back to 2020626 resolves the issue immediately.

Relevant logs

Log file attached (HTML saved as PDF).
bitwardenrs-latest-log.pdf

Originally created by @RainmakerRaw on GitHub (Jun 26, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1037  ### Subject of the issue I run Synology Docker with bitwardenrs. My SMTP provider is iCloud, and the settings work fine (emails are successfully delivered, testing in the Admin page works). As soon as I upgrade the container from 2020626 to latest, emails no longer deliver. There are 'smtp error', 400 errors, and complaints about a self-signed certificate in the chain. If I revert back to 2020626 (same Docker config file, same settings, same data dir etc) things work fine again and I can send mail perfectly. ### Your environment  * Bitwarden_rs version: 1.15.1-b34d5482  * Install method: Synology Docker using bitwardenrs/server:latest * Clients used:  * Reverse proxy and version:  * Version of mysql/postgresql:  * Other relevant information: ### Steps to reproduce  The container is launched with the following SMTP settings for iCloud (which work in 2020626): **Host**: smtp.mail.me.com **Enable SSL**: true **Explicit TLS**: false **Port**: 587 **From address**: My iCloud email address **From name**: Bitwarden_RS **Username**: My iCloud email address **Password**: My secret password **Json form auth mechanism**: (blank) **SMTP connection timeout**: 15 ### Expected behaviour  A test email delivered to my own address should be sent and deliver successfully. ### Actual behaviour  SMTP error. The logs include 400 errors, and a complaint that there's a self-signed cert in the chain (this is Apple, and it doesn't complain on the older version. Other apps send mail just fine also). As I said above, moving back to 2020626 resolves the issue immediately. ### Relevant logs  Log file attached (HTML saved as PDF). [bitwardenrs-latest-log.pdf](https://github.com/dani-garcia/bitwarden_rs/files/4834868/bitwardenrs-latest-log.pdf)

GiteaMirror closed this issue

2026-04-20 12:42:47 -05:00

GiteaMirror commented

2026-04-20 12:42:47 -05:00

@jjlin commented on GitHub (Jun 26, 2020):

It would help if you specified exact before/after versions, like 1.15.1-b34d5482. I assume 2020626 refers to something Synology-specific, but most people here are not Synology users and have no idea what that means. Also, it's hard to read logs that are in reverse order.

@jjlin commented on GitHub (Jun 26, 2020): It would help if you specified exact before/after versions, like 1.15.1-b34d5482. I assume 2020626 refers to something Synology-specific, but most people here are not Synology users and have no idea what that means. Also, it's hard to read logs that are in reverse order.

GiteaMirror commented

2026-04-20 12:42:47 -05:00

@RainmakerRaw commented on GitHub (Jun 26, 2020):

Apologies, I thought the tag on the Docker build was Docker-specific not Synology specific. The builds are as follows:

Working SMTP

1.14.2-08077833

Broken SMTP (latest available build on hub.docker.com)

1.15.1-b34d5482

I don't quite know what happened to the log file. It's ouput properly on the Synology's Docker log reader but exports in reverse. I've issued a sudo docker logs bitwardenrs > ~/latest.txt and attached that below. This should be in the correct reading order, and is simply a snippet showing what outputs to stdout when trying to send a test email from the Admin panel.

latest.txt

@RainmakerRaw commented on GitHub (Jun 26, 2020): Apologies, I thought the tag on the Docker build was Docker-specific not Synology specific. The builds are as follows: ### Working SMTP 1.14.2-08077833 ### Broken SMTP (latest available build on hub.docker.com) 1.15.1-b34d5482 I don't quite know what happened to the log file. It's ouput properly on the Synology's Docker log reader but exports in reverse. I've issued a `sudo docker logs bitwardenrs > ~/latest.txt` and attached that below. This should be in the correct reading order, and is simply a snippet showing what outputs to stdout when trying to send a test email from the Admin panel. [latest.txt](https://github.com/dani-garcia/bitwarden_rs/files/4836676/latest.txt)

GiteaMirror commented

2026-04-20 12:42:48 -05:00

@BobWs commented on GitHub (Jun 26, 2020):

Have you tried another smtp e.g. google or something else?

@BobWs commented on GitHub (Jun 26, 2020): Have you tried another smtp e.g. google or something else?

GiteaMirror commented

2026-04-20 12:42:48 -05:00

@RainmakerRaw commented on GitHub (Jun 26, 2020):

Have you tried another smtp e.g. google or something else?

No sir, not yet. The iCloud is the only mail account I have (aside from Proton Mail which is my main account, and doesn't allow using it this way). Since iCloud works in the (slightly) older version but not the newer one, it seems to be an issue with bitwardenrs rather than iCloud's SMTP? Since people are still using the latest bitwardenrs with ^eg Outlook/Live or GMail, clearly that would be a potential workaround.
However, I'd prefer to address the underlying issue if possible, and keep using my normal email account. I de-Googled myself purposefully so I'd rather not go back just becasue of a bug somewhere. :)

@RainmakerRaw commented on GitHub (Jun 26, 2020): > Have you tried another smtp e.g. google or something else? No sir, not yet. The iCloud is the only mail account I have (aside from Proton Mail which is my main account, and doesn't allow using it this way). Since iCloud works in the (slightly) older version but not the newer one, it seems to be an issue with bitwardenrs rather than iCloud's SMTP? Since people are still using the latest bitwardenrs with <sup>eg</sup> Outlook/Live or GMail, clearly that would be a potential workaround. However, I'd prefer to address the underlying issue if possible, and keep using my normal email account. I de-Googled myself purposefully so I'd rather not go back just becasue of a bug somewhere. :)

GiteaMirror commented

2026-04-20 12:42:49 -05:00

@RainmakerRaw commented on GitHub (Jun 26, 2020):

Some further info, perhaps? I made a completely new container, and (differently this time) also renamed the config.json to start truly from the beginning. I span up the container:

sudo docker run -d --name bitwardenrs \
-e SMTP_USERNAME=myname@icloud.com \
-e SMTP_SSL=true \
-e SMTP_PORT=587 \
-e SMTP_SSL=true \
-e SMTP_USERNAME=myname@icloud.com \
-e SMTP_PASSWORD=secretpassword \
-e SMTP_HOST=smtp.mail.me.com \
-e SMTP_FROM=Bitwarden_RS \
-e ADMIN_TOKEN=my_token \
-e YUBICO_SECRET_KEY=secret_key \
-e YUBICO_CLIENT_ID=12345 \
-e DOMAIN=https://bitwarden.my.domain \
-e TZ=Europe/London \
-e PGID=100 \
-e PUID=1033 \
-e LOG_FILE=/data/bitwarden.log \
-v /volume1/docker/bitwardenrs:/data \
-p 8228:80 \
bitwardenrs/server:latest

and tried to send a test email from the Admin page. Regardless of how I set the SMTP (including copying verbatim the settings that work on the previous 1.4.x version of bitwardenrs) I now get a slightly different error:

/--------------------------------------------------------------------\
|                       Starting Bitwarden_RS                        |
|                      Version 1.15.1-b34d5482                       |
|--------------------------------------------------------------------|
| This is an *unofficial* Bitwarden implementation, DO NOT use the   |
| official channels to report bugs/features, regardless of client.   |
| Send usage/configuration questions or feature requests to:         |
|   https://bitwardenrs.discourse.group/                             |
| Report suspected bugs/issues in the software itself at:            |
|   https://github.com/dani-garcia/bitwarden_rs/issues/new           |
\--------------------------------------------------------------------/

[2020-06-26 17:03:45][start][INFO] Rocket has launched from http://0.0.0.0:80
[2020-06-26 17:03:50][request][INFO] GET /admin
3.27.2 2019-02-25 16:06:06 bd49a8271d650fa89e446b42e513b595a717b9212c91dd384aab871fc1d0alt1
[2020-06-26 17:03:50][response][INFO] GET /admin (admin_page) => 200 OK
[2020-06-26 17:03:58][request][INFO] POST /admin/test/smtp/
[2020-06-26 17:03:58][error][ERROR] AddressError.
[CAUSE] MissingParts
[2020-06-26 17:03:58][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request
[2020-06-26 17:04:39][request][INFO] POST /admin/test/smtp/
[2020-06-26 17:04:39][error][ERROR] Invalid email address (no @)
[2020-06-26 17:04:39][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request
[2020-06-26 17:04:49][request][INFO] POST /admin/test/smtp/
[2020-06-26 17:04:49][error][ERROR] AddressError.
[CAUSE] MissingParts
[2020-06-26 17:04:49][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request

In case it was relevant, I also tried varying the smtp_auth_mechanism from blank to Plain to Login with no change in results. FWIW Apple says they support SSL, TLS and STARTTLS. As I said this works out of the box on the older 1.4.x release listed in my earlier reply.

I hope this is perhaps of some help in pinpointing any issue. For reference the test address I was sending to was the same as always - myname@icloud.com. After seeing the AddressError I also tried other addresses like myname@protonmail.com and got the same error.

@RainmakerRaw commented on GitHub (Jun 26, 2020): Some further info, perhaps? I made a completely new container, and (differently this time) also renamed the `config.json` to start truly from the beginning. I span up the container: ```` sudo docker run -d --name bitwardenrs \ -e SMTP_USERNAME=myname@icloud.com \ -e SMTP_SSL=true \ -e SMTP_PORT=587 \ -e SMTP_SSL=true \ -e SMTP_USERNAME=myname@icloud.com \ -e SMTP_PASSWORD=secretpassword \ -e SMTP_HOST=smtp.mail.me.com \ -e SMTP_FROM=Bitwarden_RS \ -e ADMIN_TOKEN=my_token \ -e YUBICO_SECRET_KEY=secret_key \ -e YUBICO_CLIENT_ID=12345 \ -e DOMAIN=https://bitwarden.my.domain \ -e TZ=Europe/London \ -e PGID=100 \ -e PUID=1033 \ -e LOG_FILE=/data/bitwarden.log \ -v /volume1/docker/bitwardenrs:/data \ -p 8228:80 \ bitwardenrs/server:latest ```` and tried to send a test email from the Admin page. Regardless of how I set the SMTP (including copying verbatim the settings that work on the previous 1.4.x version of bitwardenrs) I now get a slightly different error: ```` /--------------------------------------------------------------------\ | Starting Bitwarden_RS | | Version 1.15.1-b34d5482 | |--------------------------------------------------------------------| | This is an *unofficial* Bitwarden implementation, DO NOT use the | | official channels to report bugs/features, regardless of client. | | Send usage/configuration questions or feature requests to: | | https://bitwardenrs.discourse.group/ | | Report suspected bugs/issues in the software itself at: | | https://github.com/dani-garcia/bitwarden_rs/issues/new | \--------------------------------------------------------------------/ [2020-06-26 17:03:45][start][INFO] Rocket has launched from http://0.0.0.0:80 [2020-06-26 17:03:50][request][INFO] GET /admin 3.27.2 2019-02-25 16:06:06 bd49a8271d650fa89e446b42e513b595a717b9212c91dd384aab871fc1d0alt1 [2020-06-26 17:03:50][response][INFO] GET /admin (admin_page) => 200 OK [2020-06-26 17:03:58][request][INFO] POST /admin/test/smtp/ [2020-06-26 17:03:58][error][ERROR] AddressError. [CAUSE] MissingParts [2020-06-26 17:03:58][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request [2020-06-26 17:04:39][request][INFO] POST /admin/test/smtp/ [2020-06-26 17:04:39][error][ERROR] Invalid email address (no @) [2020-06-26 17:04:39][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request [2020-06-26 17:04:49][request][INFO] POST /admin/test/smtp/ [2020-06-26 17:04:49][error][ERROR] AddressError. [CAUSE] MissingParts [2020-06-26 17:04:49][response][INFO] POST /admin/test/smtp (test_smtp) => 400 Bad Request ```` In case it was relevant, I also tried varying the smtp_auth_mechanism from blank to Plain to Login with no change in results. FWIW [Apple says](https://support.apple.com/en-us/HT202304) they support SSL, TLS and STARTTLS. As I said this works out of the box on the older 1.4.x release listed in my earlier reply. I hope this is perhaps of some help in pinpointing any issue. For reference the test address I was sending to was the same as always - `myname@icloud.com`. After seeing the `AddressError` I also tried other addresses like `myname@protonmail.com` and got the same error.

GiteaMirror commented

2026-04-20 12:42:49 -05:00

@RainmakerRaw commented on GitHub (Jun 26, 2020):

I made an outlook.com account with MS just for this purpose, and it sent an email successfully first time. I give up. Hopefully if there's an underlying issue with bwrs here (breaking between versions with no external factors) then this report helps you fix it for others. I've spent hours on this so I'm just happy I have a working solution. Many thanks for your time and attention, I'm happy to troubleshoot further if someone wishes to investigate this further.

@RainmakerRaw commented on GitHub (Jun 26, 2020): I made an outlook.com account with MS just for this purpose, and it sent an email successfully first time. I give up. Hopefully if there's an underlying issue with bwrs here (breaking between versions with no external factors) then this report helps you fix it for others. I've spent hours on this so I'm just happy I have a working solution. Many thanks for your time and attention, I'm happy to troubleshoot further if someone wishes to investigate this further.

GiteaMirror commented

2026-04-20 12:42:49 -05:00

@jjlin commented on GitHub (Jun 28, 2020):

There were quite a few SMTP-related changes between 1.14.2 and 1.15.0 (mostly from updating a library dependency), and I suspect this introduced some regressions with various SMTP servers. Unfortunately, this is an area that's hard to test given the lack of access to all these random SMTP servers.

@jjlin commented on GitHub (Jun 28, 2020): There were quite a few SMTP-related changes between 1.14.2 and 1.15.0 (mostly from updating a library dependency), and I suspect this introduced some regressions with various SMTP servers. Unfortunately, this is an area that's hard to test given the lack of access to all these random SMTP servers.

GiteaMirror commented

2026-04-20 12:42:50 -05:00

@nicedevil007 commented on GitHub (Jul 14, 2020):

@RainmakerRaw so I got same error on a fresh new deployed BitwardenRS on my friends RaspberryPi.
I set it up like I did on my own environment with GMAIL. I tryed this with my own credentials that work like a charm on my environment.

So if I understand you right... you just made a new account on blablabla@outlook.com and then it worked? weird...,

@nicedevil007 commented on GitHub (Jul 14, 2020): @RainmakerRaw so I got same error on a fresh new deployed BitwardenRS on my friends RaspberryPi. I set it up like I did on my own environment with GMAIL. I tryed this with my own credentials that work like a charm on my environment. So if I understand you right... you just made a new account on blablabla@outlook.com and then it worked? weird...,

GiteaMirror commented

2026-04-20 12:42:50 -05:00

@anoxi commented on GitHub (Aug 31, 2020):

I can confirm the SMTP errors on server 1.16.3, excerpt from log:

[2020-08-31 20:39:04.120][request][INFO] POST /admin/test/smtp/
[2020-08-31 20:39:19.258][error][ERROR] SmtpError.
[CAUSE] Io(
Os {
code: 11,
kind: WouldBlock,
message: "Resource temporarily unavailable",
},

Im connecting to my mail provider via SSL, Port 465. The same mail configuration is working on another app container.

@anoxi commented on GitHub (Aug 31, 2020): I can confirm the SMTP errors on server 1.16.3, excerpt from log: > [2020-08-31 20:39:04.120][request][INFO] POST /admin/test/smtp/ > [2020-08-31 20:39:19.258][error][ERROR] SmtpError. > [CAUSE] Io( > Os { > code: 11, > kind: WouldBlock, > message: "Resource temporarily unavailable", > }, Im connecting to my mail provider via SSL, Port 465. The same mail configuration is working on another app container.

GiteaMirror commented

2026-04-20 12:42:51 -05:00

@nickbp commented on GitHub (Sep 17, 2020):

I am also seeing WouldBlock SMTP errors on the arm64 docker image of bitwardenrs/server:1.16.3. This is with Fastmail as the SMTP provider, using the settings provided here: https://www.fastmail.com/help/technical/servernamesandports.html

I've tried:

Using both port 465 or 587 as documented by Fastmail
Enabling and disabling Use explicit TLS due to the note in the Fastmail docs around STARTTLS.

In all cases, I see the same WouldBlock error. I've seen it both when testing a user signup, as well as when in the SMTP Settings interface in the admin panel. In both cases, bitwardenrs pauses for the duration of the default 15s timeout, and then displays the following error in its logs:

[2020-09-17 08:53:48.741][error][ERROR] SmtpError.
[CAUSE] Io(
    Os {
        code: 11,
        kind: WouldBlock,
        message: "Resource temporarily unavailable",
    },
)

I've tried setting LOG_LEVEL=TRACE and didn't see anything that provided more detail.

Given the symptoms, it looks like bitwardenrs is failing to open the connection at all.

@nickbp commented on GitHub (Sep 17, 2020): I am also seeing `WouldBlock` SMTP errors on the arm64 docker image of `bitwardenrs/server:1.16.3`. This is with Fastmail as the SMTP provider, using the settings provided here: https://www.fastmail.com/help/technical/servernamesandports.html I've tried: - Using both port 465 or 587 as documented by Fastmail - Enabling and disabling `Use explicit TLS` due to the note in the Fastmail docs around STARTTLS. In all cases, I see the same `WouldBlock` error. I've seen it both when testing a user signup, as well as when in the `SMTP Settings` interface in the admin panel. In both cases, bitwardenrs pauses for the duration of the default 15s timeout, and then displays the following error in its logs: ``` [2020-09-17 08:53:48.741][error][ERROR] SmtpError. [CAUSE] Io( Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable", }, ) ``` I've tried setting `LOG_LEVEL=TRACE` and didn't see anything that provided more detail. Given the symptoms, it looks like bitwardenrs is failing to open the connection at all.

GiteaMirror commented

2026-04-20 12:42:51 -05:00

@nickbp commented on GitHub (Sep 17, 2020):

I tried looking at this again this morning, and it turns out that I wasn't testing port 587 at all when trying things out via the admin panel, because I was just editing the SMTP fields in place and then trying to send a test email. Instead I should have SAVED the config by scrolling to the bottom of the admin panel, THEN going back into the SMTP section and sending a test email.

Once I had configured SMTP to use port 587 (and made sure that I was actually saving the config), the test email went through fine.

For reference, here's a full listing of the SMTP settings that I used to successfully send a test email via Fastmail SMTP:

Enabled: true
Host: smtp.fastmail.com
Enable SSL: true
Use explicit TLS: false (setting this to true fails with SSL "wrong version number" error)
Port: 587 (setting this to 465 fails with aforementioned WouldBlock error)
From address: <anything>
From name: Bitwarden_RS (default)
Username: <username>@fastmail.com
Password: <fastmail-app-password-with-smtp-access>
Json form auth mechanism: <blank> (default)
SMTP connection timeout: 15 (default)
Server name sent during HELO: <blank> (default)

Summary: It looks like the WouldBlock error indicates an issue with setting up the SSL handshake, and it may be possible by trying an alternate port? But don't forget to explicitly save the config before sending the test email!

@nickbp commented on GitHub (Sep 17, 2020): I tried looking at this again this morning, and it turns out that I wasn't testing port 587 at all when trying things out via the admin panel, because I was just editing the SMTP fields in place and then trying to send a test email. Instead I should have SAVED the config by scrolling to the bottom of the admin panel, THEN going back into the SMTP section and sending a test email. Once I had configured SMTP to use port 587 (and made sure that I was actually saving the config), the test email went through fine. For reference, here's a full listing of the SMTP settings that I used to successfully send a test email via Fastmail SMTP: - Enabled: `true` - Host: `smtp.fastmail.com` - Enable SSL: `true` - Use explicit TLS: `false` (setting this to true fails with SSL "wrong version number" error) - Port: `587` (setting this to 465 fails with aforementioned WouldBlock error) - From address: `<anything>` - From name: `Bitwarden_RS` (default) - Username: `<username>@fastmail.com` - Password: `<fastmail-app-password-with-smtp-access>` - Json form auth mechanism: `<blank>` (default) - SMTP connection timeout: `15` (default) - Server name sent during HELO: `<blank>` (default) Summary: It looks like the `WouldBlock` error indicates an issue with setting up the SSL handshake, and it may be possible by trying an alternate port? But don't forget to explicitly save the config before sending the test email!

GiteaMirror commented

2026-04-20 12:42:52 -05:00

@BlackDex commented on GitHub (Sep 22, 2020):

@RainmakerRaw

I'm glad it is all working now :).

What i think happened is that when looking at your env variables you posted on the 26th of July is this -e SMTP_FROM=Bitwarden_RS \.
That variable should contain an email address instead of just a name. For that you need SMTP_FROM_NAME. The error message indicates missing parts of the mail address.

The second error seems to be a connectivity issue to the server, either the hostname or port or both were incorrect and would cause this error.

@BlackDex commented on GitHub (Sep 22, 2020): @RainmakerRaw I'm glad it is all working now :). What i think happened is that when looking at your env variables you posted on the 26th of July is this `-e SMTP_FROM=Bitwarden_RS \`. That variable should contain an email address instead of just a name. For that you need `SMTP_FROM_NAME`. The error message indicates missing parts of the mail address. The second error seems to be a connectivity issue to the server, either the hostname or port or both were incorrect and would cause this error.

GiteaMirror commented

2026-04-20 12:42:52 -05:00

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

I tried looking at this again this morning, and it turns out that I wasn't testing port 587 at all when trying things out via the admin panel, because I was just editing the SMTP fields in place and then trying to send a test email. Instead I should have SAVED the config by scrolling to the bottom of the admin panel, THEN going back into the SMTP section and sending a test email.

This! I somehow expected the test email to go through whichever server is currently displayed... Didn't think to save and wondered why it wasn't working...

@tschoesi commented on GitHub (Oct 12, 2020): > I tried looking at this again this morning, and it turns out that I wasn't testing port 587 at all when trying things out via the admin panel, because I was just editing the SMTP fields in place and then trying to send a test email. Instead I should have SAVED the config by scrolling to the bottom of the admin panel, THEN going back into the SMTP section and sending a test email. > This! I somehow expected the test email to go through whichever server is currently displayed... Didn't think to save and wondered why it wasn't working...

GiteaMirror commented

2026-04-20 12:42:53 -05:00

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

That is a bit confusing indeed. Lets see if we can make that more clear or at least warn that you have to save first :).

So, it is working now then right?

@BlackDex commented on GitHub (Oct 12, 2020): That is a bit confusing indeed. Lets see if we can make that more clear or at least warn that you have to save first :). So, it is working now then right?

GiteaMirror commented

2026-04-20 12:42:53 -05:00

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

I didn't open this issue, I just came here looking because my "new configuration" didn't seem to work after switching email providers...
But yes, for me it's working fine now! just had to hit save first

@tschoesi commented on GitHub (Oct 12, 2020): I didn't open this issue, I just came here looking because my "new configuration" didn't seem to work after switching email providers... But yes, for me it's working fine now! just had to hit save first

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#9545