starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-02-05 00:29:40 +03:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

problem setting up smtp to host postfix from docker #429

New Issue
Closed
opened 2026-02-04 20:28:16 +03:00 by OVERLORD · 11 comments
OVERLORD commented 2026-02-04 20:28:16 +03:00
Owner
Copy Link

Originally created by @baahver on GitHub (Sep 24, 2019).

I have setup bitwarden_rs on a ubuntu vps within a docker. Connection is made by reverse proxy. So I'm anble to conect to bitwarden as: bitwarden.example.com. without portnumber.

But I am not able to setup smtp to my host postfix. Setting smtp on any other device was never a problem. Normally I'm using: mail.example.com, ssl/tls, port 465, username: info@example.com and password.
I tried localhost, mail.example.com, smtp.example.com, ssl and/or tls, port 465, 587 and even 25. Nothing is working.

But I was able to set up smtp to a gmail account. But that is not a desired smtp for me.
Is there an issue that I have not seen? Or is there anything else what could give me these problems? The log files do not mention anything about the smtp.

Edit: I searched a little further and found out that on Bitwarden server there are/were smtp problems. Setting smtp_authType=LOGIN or PLAIN could be a solution. I tried these, but it didn't help. Is smtp_authType=LOGIN a valid setting on bitwarden_rs?

Originally created by @baahver on GitHub (Sep 24, 2019). I have setup bitwarden_rs on a ubuntu vps within a docker. Connection is made by reverse proxy. So I'm anble to conect to bitwarden as: bitwarden.example.com. without portnumber. But I am not able to setup smtp to my host postfix. Setting smtp on any other device was never a problem. Normally I'm using: mail.example.com, ssl/tls, port 465, username: info@example.com and password. I tried localhost, mail.example.com, smtp.example.com, ssl and/or tls, port 465, 587 and even 25. Nothing is working. But I was able to set up smtp to a gmail account. But that is not a desired smtp for me. Is there an issue that I have not seen? Or is there anything else what could give me these problems? The log files do not mention anything about the smtp. Edit: I searched a little further and found out that on Bitwarden server there are/were smtp problems. Setting smtp_authType=LOGIN or PLAIN could be a solution. I tried these, but it didn't help. Is smtp_authType=LOGIN a valid setting on bitwarden_rs?
OVERLORD commented 2026-02-04 20:28:25 +03:00
Author
Owner
Copy Link

@baahver commented on GitHub (Sep 27, 2019):

No one can help me with this?

@baahver commented on GitHub (Sep 27, 2019): No one can help me with this?
OVERLORD commented 2026-02-04 20:28:29 +03:00
Author
Owner
Copy Link

@Ayitaka commented on GitHub (Oct 2, 2019):

I use bitwarden_rs and a pretty standard virtual mailbox configuration of postfix and have no problem sending emails using just the following settings:

   SMTP_HOST: "domain.com"
   SMTP_FROM: "no-reply@domain.com"
   SMTP_PORT: "587"
   SMTP_SSL: "true"
   SMTP_USERNAME: "username@domain.com"
   SMTP_PASSWORD: "sUp3rs3Cr3TP@$$w0rd"

So I am inclined to think it has something to do with the way you have your postfix setup. Check your logs at /var/log/mail.log and see what it says whenever your bitwarden_rs tries to connect to send an email.

@Ayitaka commented on GitHub (Oct 2, 2019): I use bitwarden_rs and a pretty standard virtual mailbox configuration of postfix and have no problem sending emails using just the following settings: ``` SMTP_HOST: "domain.com" SMTP_FROM: "no-reply@domain.com" SMTP_PORT: "587" SMTP_SSL: "true" SMTP_USERNAME: "username@domain.com" SMTP_PASSWORD: "sUp3rs3Cr3TP@$$w0rd" ``` So I am inclined to think it has something to do with the way you have your postfix setup. Check your logs at /var/log/mail.log and see what it says whenever your bitwarden_rs tries to connect to send an email.
OVERLORD commented 2026-02-04 20:28:31 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (Oct 7, 2019):

@baahver, try to increase the logging option, and see what happens.
And don't forget to configure the DOMAIN setting, else the e-mails will contain wrong links.
In a more extreme option you could try to do a tcpdump on the IP mail-server on the host where the bitwarden_rs docker container is running. To see if a connection attempt is tried at all.

@BlackDex commented on GitHub (Oct 7, 2019): @baahver, try to increase the logging option, and see what happens. And don't forget to configure the `DOMAIN` setting, else the e-mails will contain wrong links. In a more extreme option you could try to do a tcpdump on the IP mail-server on the host where the bitwarden_rs docker container is running. To see if a connection attempt is tried at all.
OVERLORD commented 2026-02-04 20:28:34 +03:00
Author
Owner
Copy Link

@icicimov commented on GitHub (Dec 15, 2019):

I have the same problem with Postfix server with STARTTLS using the same setup as given above by @Ayitaka with different domain and credentials of course. This is the docker log:

[2019-12-15 06:45:05][bitwarden_rs::api::core::accounts][ERROR] Error sending welcome email: Error sending email. handshake error

and on the mail server I can see:

postfix/submission/smtpd[4032]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:s3_pkt.c:1487:SSL alert number 48:
postfix/submission/smtpd[4032]: lost connection after STARTTLS from unknown[<IP-obfuscated>]

Seems like bitwarden is not able to verify my Let's Encrypt issued certificate, I'm using the bitwardenrs/server:1.13.0-alpine docker image. My Postfix mail server mail.icicimov.com has been working fine for years and the SSL cert is valid for sure:

$ openssl x509 -noout -issuer -subject -dates -ext subjectAltName -in cert.pem
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
subject=CN = icicimov.com
notBefore=Nov 30 12:09:07 2019 GMT
notAfter=Feb 28 12:09:07 2020 GMT
X509v3 Subject Alternative Name: 
    DNS:blog.icicimov.com, DNS:icicimov.com, DNS:mail.icicimov.com, DNS:www.icicimov.com
@icicimov commented on GitHub (Dec 15, 2019): I have the same problem with Postfix server with STARTTLS using the same setup as given above by @Ayitaka with different domain and credentials of course. This is the docker log: ``` [2019-12-15 06:45:05][bitwarden_rs::api::core::accounts][ERROR] Error sending welcome email: Error sending email. handshake error ``` and on the mail server I can see: ``` postfix/submission/smtpd[4032]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:s3_pkt.c:1487:SSL alert number 48: postfix/submission/smtpd[4032]: lost connection after STARTTLS from unknown[<IP-obfuscated>] ``` Seems like bitwarden is not able to verify my Let's Encrypt issued certificate, I'm using the `bitwardenrs/server:1.13.0-alpine` docker image. My Postfix mail server mail.icicimov.com has been working fine for years and the SSL cert is valid for sure: ``` $ openssl x509 -noout -issuer -subject -dates -ext subjectAltName -in cert.pem issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 subject=CN = icicimov.com notBefore=Nov 30 12:09:07 2019 GMT notAfter=Feb 28 12:09:07 2020 GMT X509v3 Subject Alternative Name: DNS:blog.icicimov.com, DNS:icicimov.com, DNS:mail.icicimov.com, DNS:www.icicimov.com ```
OVERLORD commented 2026-02-04 20:28:36 +03:00
Author
Owner
Copy Link

@Ayitaka commented on GitHub (Dec 15, 2019):

Everything looks fine with your cert.

From my google searches, it seems to be an issue with a client-side cert? Do you have it setup to check client authentication via certs?

In your main.cf, smtpd_tls_CAfile or smtpd_tls_CApath would be related to that and info can be found here.

@Ayitaka commented on GitHub (Dec 15, 2019): Everything looks fine with your cert. From my [google searches](https://www.google.com/search?q=ssl+routines+ssl3_read_bytes+tlsv1+alert+unknown+ca+s3_pkt+c+1487+ssl+alert+number+48+site:serverfault.com), it seems to be an issue with a client-side cert? Do you have it setup to check client authentication via certs? In your main.cf, smtpd_tls_CAfile or smtpd_tls_CApath would be related to that and info can be found [here](http://www.postfix.org/postconf.5.html#smtpd_tls_CAfile). ```
OVERLORD commented 2026-02-04 20:28:39 +03:00
Author
Owner
Copy Link

@baahver commented on GitHub (Dec 15, 2019):

I finally fixed the issue for my situation!
In /etc/postfix/main.cf I added: 172.17.0.0/24 to 'mynetworks'
and:
-e SMTP_HOST=172.17.0.1
-e SMTP_SSL=false
-e SMTP_FROM=info@mydomain.com
-e SMTP_USERNAME=info@mydomain.com
-e SMTP_PASSWORD=xxxxxxxxxx
I assume the first two (SMTP_HOST=172.17.0.1 and SMTP_SSL=false) did the trick in my case.
Not sure why I did not do this before. I was trying to connect via ssl to smtp.mydomain.com.

@baahver commented on GitHub (Dec 15, 2019): I finally fixed the issue for my situation! In /etc/postfix/main.cf I added: 172.17.0.0/24 to 'mynetworks' and: -e SMTP_HOST=172.17.0.1 \ -e SMTP_SSL=false \ -e SMTP_FROM=info@mydomain.com \ -e SMTP_USERNAME=info@mydomain.com \ -e SMTP_PASSWORD=xxxxxxxxxx \ I assume the first two (SMTP_HOST=172.17.0.1 and SMTP_SSL=false) did the trick in my case. Not sure why I did not do this before. I was trying to connect via ssl to smtp.mydomain.com.
OVERLORD commented 2026-02-04 20:28:41 +03:00
Author
Owner
Copy Link

@icicimov commented on GitHub (Dec 16, 2019):

From my google searches, it seems to be an issue with a client-side cert? Do you have it setup to check client authentication via certs?

I'm not using client certificates and the ciphers are not limited to TLS1.3 for sure. Maybe the client gets confused and is trying to send the TLS cert from the env var as client cert trying to authenticate? Does the SMTP_SSL option actually cover STARTTLS too? Usually a client would have SSL (port 465) and STARTTLS (port 25/587) as separate options.

These are some of the Postfix settings:

smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_sasl_tls_security_options = noanonymous

Notice the smtpd_tls_auth_only settings here that might be important. From the docs:

To maintain compatibility with non-TLS clients, the default is to 
accept AUTH without encryption. In order to change this behavior, 
set "smtpd_tls_auth_only = yes".

It all points to client issues with TLS, more specifically I suspect the client does not support authentication over TLS (as explained above) but maybe I'm wrong. Testing with openssl with (-starttls smtp option) from the same host that the container is running on shows no TLS issues.

This is with debug enabled but it does not say much about the error:

[2019-12-16 11:06:52][lettre::smtp::client][DEBUG] Wrote: STARTTLS<CRLF>
[2019-12-16 11:06:52][lettre::smtp::client][DEBUG] Read: 220 2.0.0 Ready to start TLS<CRLF>
[2019-12-16 11:06:52][lettre::smtp::client][DEBUG] Wrote: QUIT<CRLF>
[2019-12-16 11:06:52][bitwarden_rs::api::core::accounts][ERROR] Error sending delete account email: Error sending email. handshake error

We can see the server replying with Ready to start TLS after which the client quits the connection. Also why is it even sending delete account email I wonder? And second the response in the UI is always a pop-up saying email sent successfully.

@icicimov commented on GitHub (Dec 16, 2019): > From my [google searches](https://www.google.com/search?q=ssl+routines+ssl3_read_bytes+tlsv1+alert+unknown+ca+s3_pkt+c+1487+ssl+alert+number+48+site:serverfault.com), it seems to be an issue with a client-side cert? Do you have it setup to check client authentication via certs? I'm not using client certificates and the ciphers are not limited to TLS1.3 for sure. Maybe the client gets confused and is trying to send the TLS cert from the env var as client cert trying to authenticate? Does the SMTP_SSL option actually cover STARTTLS too? Usually a client would have SSL (port 465) and STARTTLS (port 25/587) as separate options. These are some of the Postfix settings: ``` smtpd_use_tls = yes smtpd_tls_auth_only = yes smtpd_sasl_tls_security_options = noanonymous ``` Notice the `smtpd_tls_auth_only` settings here that might be important. From the docs: ``` To maintain compatibility with non-TLS clients, the default is to accept AUTH without encryption. In order to change this behavior, set "smtpd_tls_auth_only = yes". ``` It all points to client issues with TLS, more specifically I suspect the client does not support authentication over TLS (as explained above) but maybe I'm wrong. Testing with openssl with (`-starttls smtp` option) from the same host that the container is running on shows no TLS issues. This is with debug enabled but it does not say much about the error: ``` [2019-12-16 11:06:52][lettre::smtp::client][DEBUG] Wrote: STARTTLS<CRLF> [2019-12-16 11:06:52][lettre::smtp::client][DEBUG] Read: 220 2.0.0 Ready to start TLS<CRLF> [2019-12-16 11:06:52][lettre::smtp::client][DEBUG] Wrote: QUIT<CRLF> [2019-12-16 11:06:52][bitwarden_rs::api::core::accounts][ERROR] Error sending delete account email: Error sending email. handshake error ``` We can see the server replying with `Ready to start TLS` after which the client quits the connection. Also why is it even sending delete account email I wonder? And second the response in the UI is always a pop-up saying email sent successfully.
OVERLORD commented 2026-02-04 20:28:47 +03:00
Author
Owner
Copy Link

@icicimov commented on GitHub (Dec 17, 2019):

Solved. The Postfix cert file was missing the LE X3 certificate, the script renewing the certificate automatically failed to concatenate the file properly.

@icicimov commented on GitHub (Dec 17, 2019): Solved. The Postfix cert file was missing the LE X3 certificate, the script renewing the certificate automatically failed to concatenate the file properly.
OVERLORD commented 2026-02-04 20:28:50 +03:00
Author
Owner
Copy Link

@baahver commented on GitHub (Dec 17, 2019):

@icicimov Can you give a clue how you solved this? On what kind of server are you? Linux I assume? I find some information about X1 and X3 mixup, but all is about windows IIS servers. I'm on Ubuntu server.

@baahver commented on GitHub (Dec 17, 2019): @icicimov Can you give a clue how you solved this? On what kind of server are you? Linux I assume? I find some information about X1 and X3 mixup, but all is about windows IIS servers. I'm on Ubuntu server.
OVERLORD commented 2026-02-04 20:28:58 +03:00
Author
Owner
Copy Link

@icicimov commented on GitHub (Dec 18, 2019):

@baahver for the my specific error make sure you have the full CA chain in the smtpd_tls_cert_file in postfix configuration file.

@icicimov commented on GitHub (Dec 18, 2019): @baahver for the my specific error make sure you have the full CA chain in the `smtpd_tls_cert_file` in postfix configuration file.
OVERLORD commented 2026-02-04 20:29:04 +03:00
Author
Owner
Copy Link

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

Closed due to inactivity.

@dani-garcia commented on GitHub (May 14, 2020): Closed due to inactivity.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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 Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#429
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?