[GH-ISSUE #5856] New device registration awaits SMTP which results in bitwarden client timeouts. #35216

New Issue

GiteaMirror · 2026-07-13T20:00:40-05:00

GiteaMirror commented

2026-07-13 20:00:40 -05:00

Originally created by @mattpr on GitHub (May 15, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5856

Vaultwarden Support String

Everything is in the discussion

Vaultwarden Build Version

v1.33.2

Deployment method

Manually Extracted from Container Image

Custom deployment method

not relevant.

Reverse Proxy

nginx (not relevant)

Host/Server Operating System

Linux

Operating System Version

Ubuntu 22 (not relevant)

Clients

Android

Client Version

2025.4.0 (20100) and 2025.5.0 (debug/standard)

Steps To Reproduce

Discussion here (just see last message).

Issue is when a new device is logged into to vaultwarden server AND smtp is enabled... the code awaits the email to be sent (to check for SMTP error)...meanwhile blocking the HTTP response.

If SMTP is slow (it often is) this significantly delays the HTTP response. Client timeouts (android client empirical testing) are 10 seconds and they hang up resulting in unexpected errors for users when vaultwarden is slow (because of slow SMTP). This is also bad user experience because when they first use vaultwarden on a new device they experience very slow logins unless vaultwarden is using a very fast SMTP server.

The fix is that this email sending should be moved into an async function that is not awaited itself by the new device code (so we don't block http response) but if there is an SMTP error it can still be caught and logged within the new async function.

Expected Result

vaultwarden should not block new device http response waiting on sending SMTP notification.

Actual Result

vaultwarden blocks new device HTTP response until SMTP is complete which can take a long time with slow SMTP, leading to 18 second http responses which lead to bitwarden client timeouts (10 seconds) and unexpected errors...as well as slow first logins which makes users think vaultwarden is slow.

Logs

See the discussion for lots of logs.

Screenshots or Videos

No response

Additional Context

No response

Originally created by @mattpr on GitHub (May 15, 2025). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5856 ### Vaultwarden Support String Everything is in the [discussion](https://github.com/dani-garcia/vaultwarden/discussions/5852#discussioncomment-13142675) ### Vaultwarden Build Version v1.33.2 ### Deployment method Manually Extracted from Container Image ### Custom deployment method not relevant. ### Reverse Proxy nginx (not relevant) ### Host/Server Operating System Linux ### Operating System Version Ubuntu 22 (not relevant) ### Clients Android ### Client Version 2025.4.0 (20100) and 2025.5.0 (debug/standard) ### Steps To Reproduce Discussion [here](https://github.com/dani-garcia/vaultwarden/discussions/5852#discussioncomment-13142675) (just see last message). Issue is when a new device is logged into to vaultwarden server AND smtp is enabled... [the code](https://github.com/dani-garcia/vaultwarden/blob/ad8484a2d511d47880742634173d94c03cb2bbf4/src/api/identity.rs#L268) `awaits` the email to be sent (to check for SMTP error)...meanwhile blocking the HTTP response. If SMTP is slow (it often is) this significantly delays the HTTP response. Client timeouts (android client empirical testing) are 10 seconds and they hang up resulting in unexpected errors for users when vaultwarden is slow (because of slow SMTP). This is also bad user experience because when they first use vaultwarden on a new device they experience very slow logins unless vaultwarden is using a very fast SMTP server. The fix is that this email sending should be moved into an async function that is not awaited itself by the new device code (so we don't block http response) but if there is an SMTP error it can still be caught and logged within the new async function. ### Expected Result vaultwarden should not block new device http response waiting on sending SMTP notification. ### Actual Result vaultwarden blocks new device HTTP response until SMTP is complete which can take a long time with slow SMTP, leading to 18 second http responses which lead to bitwarden client timeouts (10 seconds) and unexpected errors...as well as slow first logins which makes users think vaultwarden is slow. ### Logs ```text See the discussion for lots of logs. ``` ### Screenshots or Videos _No response_ ### Additional Context _No response_

GiteaMirror added the enhancement bug low priority labels 2026-07-13 20:00:41 -05:00

GiteaMirror commented

2026-07-13 20:00:43 -05:00

@BlackDex commented on GitHub (May 15, 2025):

My question would be, why is your mail server so slow?
I sometimes have something similar when testing, but never this long of a timeout. And my reverse proxy doesn't cut the connection either that quick.

While trying to send the mail in the background or other thread might be an option, it isn't that trivial.

@BlackDex commented on GitHub (May 15, 2025): My question would be, why is your mail server so slow? I sometimes have something similar when testing, but never this long of a timeout. And my reverse proxy doesn't cut the connection either that quick. While trying to send the mail in the background or other thread might be an option, it isn't that trivial.

GiteaMirror commented

2026-07-13 20:00:43 -05:00

@mattpr commented on GitHub (May 16, 2025):

There are lots of reasons an SMTP server can be slow including milters/filters. And yes if the SMTP server was faster this problem would not appear. However SMTP speed (or speed of any API/service/server) is not something that can be guaranteed. So counting on that as a design requirement for vaultwarden seems like this will just come up with different users again and again.

What is guaranteed is the 10 second bitwarden client timeout and that vaultwarden server logs do not make it easy to see that the client hungup before response (unless you enable trace and know what you are looking for) or why vaultwarden is so slow to respond to the client.

Not sure why vaultwarden would want to block an HTTP response while waiting for SMTP notification to go out unless require_device_email is enabled. Especially since there is a hard timeout of 10 seconds on the bitwarden clients and so anything unnecessary that slows down http responses creates a confusing user experience if there are random errors that show up and disappear as an SMTP servers speeds up or slows down.

Admittedly I don't know enough about rust async/await to say anything regarding the complexity here. But I would expect you should be able to conditionally say I either want to await the smtp result (or not) depending on whether require_device_email is enabled. ie, allow SMTP sending to finish (or log error) async/AFTER the http response has been sent in the case where require_device_email is disabled (default).

If we don't stop SMTP from blocking http responses when not needed, another improvement would be to improve server-side (vaultwarden) logging around these types of events...so at least the vaultwarden logs make it obvious there is probably a client error and why. Will reduce support discussions from folks like me in the future.

The client reports the error (only useful if you can reproduce the issue and have logging on the client).

The server doesn't report anything in this case unless you enable trace logging and look for it in which case it tells you the client disconnected before the http response was sent... which implies the client probably shows a timeout error. But of course unless you enable trace and are looking for this little hint you don't see anything wrong on the server side. So a different improvement would be to surface the "client disappeared" before http response at a warn level (instead of trace) with a bit of context to help others troubleshoot this more easily when they inevitably run into the same problem (e.g. warn message could look something like: client disconnected before http response, possible network problem or client timeout because we took too long to respond).

The only other tell in vaultwarden's logs is the long delay between request/response but you have to notice that in the timestamps, the slow response is not called out by vaultwarden in the logs. So while at it, could add a general warning when vaultwarden is slow to respond (time between request and response is more than X seconds).

If SMTP sending is going to block critical request/response path then adding a log warning about a SMTP server would help vaultwarden administrator see what exactly is causing the slow response which in turn is causing the client timeout.

@mattpr commented on GitHub (May 16, 2025): There are lots of reasons an SMTP server can be slow including milters/filters. And yes if the SMTP server was faster this problem would not appear. However SMTP speed (or speed of any API/service/server) is not something that can be guaranteed. So counting on that as a design requirement for vaultwarden seems like this will just come up with different users again and again. What is guaranteed is the 10 second bitwarden client timeout and that vaultwarden server logs do not make it easy to see that the client hungup before response (unless you enable trace and know what you are looking for) or why vaultwarden is so slow to respond to the client. Not sure why vaultwarden would want to block an HTTP response while waiting for SMTP notification to go out unless `require_device_email` is enabled. Especially since there is a hard timeout of 10 seconds on the bitwarden clients and so anything unnecessary that slows down http responses creates a confusing user experience if there are random errors that show up and disappear as an SMTP servers speeds up or slows down. Admittedly I don't know enough about rust async/await to say anything regarding the complexity here. But I would expect you should be able to conditionally say I either want to `await` the smtp result (or not) depending on whether `require_device_email` is enabled. ie, allow SMTP sending to finish (or log error) async/AFTER the http response has been sent in the case where `require_device_email` is disabled (default). If we don't stop SMTP from blocking http responses when not needed, another improvement would be to improve server-side (vaultwarden) logging around these types of events...so at least the vaultwarden logs make it obvious there is probably a client error and why. Will reduce support discussions from folks like me in the future. The client reports the error (only useful if you can reproduce the issue and have logging on the client). The server doesn't report anything in this case unless you enable `trace` logging and look for it in which case it tells you the client disconnected before the http response was sent... which implies the client probably shows a timeout error. But of course unless you enable trace and are looking for this little hint you don't see anything wrong on the server side. So a different improvement would be to surface the "client disappeared" before http response at a warn level (instead of trace) with a bit of context to help others troubleshoot this more easily when they inevitably run into the same problem (e.g. warn message could look something like: `client disconnected before http response, possible network problem or client timeout because we took too long to respond`). The only other tell in vaultwarden's logs is the long delay between request/response but you have to notice that in the timestamps, the slow response is not called out by vaultwarden in the logs. So while at it, could add a general warning when vaultwarden is slow to respond (time between request and response is more than X seconds). If SMTP sending is going to block critical request/response path then adding a log warning about a SMTP server would help vaultwarden administrator see what exactly is causing the slow response which in turn is causing the client timeout.

GiteaMirror commented

2026-07-13 20:00:44 -05:00

@BlackDex commented on GitHub (May 16, 2025):

We would need to spawn it on a different thread, it isn't as simple as just removing the .await.

@BlackDex commented on GitHub (May 16, 2025): We would need to spawn it on a different thread, it isn't as simple as just removing the `.await`.

GiteaMirror commented

2026-07-13 20:00:44 -05:00

@mattpr commented on GitHub (May 19, 2025):

And my reverse proxy doesn't cut the connection either that quick.

Just to make sure there wasn't some misunderstanding here... There is no timeout happening from the reverse proxy.
The timeout is from the Bitwarden android client.

The nginx reverse proxy records the bitwarden client disconnect as a 499.
vaultwarden does not record anything unless you enable trace in which case you see one line that indicates the client hungup before vaultwarden responded.

From empirical testing, the bitwarden (android) client has a apparent 10 second timeout. So anything that causes vaultwarden to take more than 10 seconds to respond will result in client showing user an error (e.g. This is not a recognized Bitwarden server. You may need to check with your provider or update your server.).

We would need to spawn it on a different thread, it isn't as simple as just removing the .await.

If preventing SMTP sending from blocking HTTP response is quite complicated, it would at least be good to surface these potential issues in the logs as a WARN. This way a reported client error has corresponding server logging explaining what the issue is. Not sure how many people want to leave servers running at INFO or TRACE...and as this case can result in client errors, I think a warning is appropriate.

There are a few edge cases that would be useful to have log warnings about here...

slow request/response pair. anytime vaultwarden is making a response more than ___ seconds after the request came in, emit a warning about slow response ("this may cause client timeouts"). Not sure the right number. Slow responses may indicate other issues (disk, database, slow SMTP, etc).
slow SMTP server (specific case) so users have an idea what is making vaultwarden slow (otherwise they have to look at the code and turn SMTP on/off to empirically test if SMTP is the culprit.
client disconnects before response. this is currently logged at debug/trace and would be good to have at WARN. client disconnect before response could be due to something like a network change...but can also be a timeout because we were too slow. In any case the bitwarden client probably shows an error so would be good to have a server log line that correlates to that client-side error.

@mattpr commented on GitHub (May 19, 2025): > And my reverse proxy doesn't cut the connection either that quick. Just to make sure there wasn't some misunderstanding here... There is no timeout happening from the reverse proxy. The timeout is from the Bitwarden android client. The nginx reverse proxy records the bitwarden client disconnect as a `499`. vaultwarden does not record anything unless you enable trace in which case you see one line that indicates the client hungup before vaultwarden responded. From empirical testing, the bitwarden (android) client has a apparent 10 second timeout. So anything that causes vaultwarden to take more than 10 seconds to respond will result in client showing user an error (e.g. `This is not a recognized Bitwarden server. You may need to check with your provider or update your server.`). > We would need to spawn it on a different thread, it isn't as simple as just removing the .await. If preventing SMTP sending from blocking HTTP response is quite complicated, it would at least be good to surface these potential issues in the logs as a `WARN`. This way a reported client error has corresponding server logging explaining what the issue is. Not sure how many people want to leave servers running at INFO or TRACE...and as this case can result in client errors, I think a warning is appropriate. There are a few edge cases that would be useful to have log warnings about here... - slow request/response pair. anytime vaultwarden is making a response more than ___ seconds after the request came in, emit a warning about slow response ("this may cause client timeouts"). Not sure the right number. Slow responses may indicate other issues (disk, database, slow SMTP, etc). - slow SMTP server (specific case) so users have an idea what is making vaultwarden slow (otherwise they have to look at the code and turn SMTP on/off to empirically test if SMTP is the culprit. - client disconnects before response. this is currently logged at debug/trace and would be good to have at WARN. client disconnect before response could be due to something like a network change...but can also be a timeout because we were too slow. In any case the bitwarden client probably shows an error so would be good to have a server log line that correlates to that client-side error.

GiteaMirror commented

2026-07-13 20:00:45 -05:00

@BlackDex commented on GitHub (May 19, 2025):

I doubt that adding a warn on all disconnects would be very useful, that would probably clutter the logs too much in my opinion. If users experiences issues, then setting the log level to trace or debug is probably the best option and trigger the issue and check the resulting logs then.

@BlackDex commented on GitHub (May 19, 2025): I doubt that adding a warn on all disconnects would be very useful, that would probably clutter the logs too much in my opinion. If users experiences issues, then setting the log level to trace or debug is probably the best option and trigger the issue and check the resulting logs then.

GiteaMirror commented

2026-07-13 20:00:45 -05:00

@mattpr commented on GitHub (May 19, 2025):

I doubt that adding a warn on all disconnects would be very useful, that would probably clutter the logs too much in my opinion.

Could be. I don't know how often a client disconnects before vaultwarden can respond, but as it will generally raise a client-side error (because request can't be completed from client's point of view) it does seem useful to have corresponding server-side warning.

In my case because I experienced the error and could reproduce it, I was able to turn on trace logging and spot the disconnect there as well. For another user reporting an error, they may not be able or available to reproduce the issue.

Even though I was able to reproduce, the issue was not obvious to me either. I eventually spotted the 499 on the nginx access log side. But it wasn't super obvious at first look that there was anything wrong on the server side, only the client error. Then noticing the 499 on nginx led me to look at the vaultwarden timestamps and realize how slow the response was. Seems like these cases could be made more obvious in the server side logs to aid in troubleshooting rather than guess and checking.

@mattpr commented on GitHub (May 19, 2025): > I doubt that adding a warn on all disconnects would be very useful, that would probably clutter the logs too much in my opinion. Could be. I don't know how often a client disconnects before vaultwarden can respond, but as it will generally raise a client-side error (because request can't be completed from client's point of view) it does seem useful to have corresponding server-side warning. In my case because I experienced the error and could reproduce it, I was able to turn on trace logging and spot the disconnect there as well. For another user reporting an error, they may not be able or available to reproduce the issue. Even though I was able to reproduce, the issue was not obvious to me either. I eventually spotted the 499 on the nginx access log side. But it wasn't super obvious at first look that there was anything wrong on the server side, only the client error. Then noticing the 499 on nginx led me to look at the vaultwarden timestamps and realize how slow the response was. Seems like these cases could be made more obvious in the server side logs to aid in troubleshooting rather than guess and checking.

GiteaMirror commented

2026-07-13 20:00:45 -05:00

@dislazy commented on GitHub (May 26, 2025):

When I log in to a new device recently, I receive multiple emails during the email verification process.

@dislazy commented on GitHub (May 26, 2025): When I log in to a new device recently, I receive multiple emails during the email verification process.

GiteaMirror commented

2026-07-13 20:00:46 -05:00

@mattpr commented on GitHub (May 26, 2025):

When I log in to a new device recently, I receive multiple emails during the email verification process.

Doesn't sound related to this issue.

@mattpr commented on GitHub (May 26, 2025): > When I log in to a new device recently, I receive multiple emails during the email verification process. Doesn't sound related to this issue.

GiteaMirror commented

2026-07-13 20:00:46 -05:00

@dislazy commented on GitHub (May 27, 2025):

When I log in to a new device recently, I receive multiple emails during the email verification process.

Doesn't sound related to this issue.

ok

@dislazy commented on GitHub (May 27, 2025): > > When I log in to a new device recently, I receive multiple emails during the email verification process. > > Doesn't sound related to this issue. ok

GiteaMirror commented

2026-07-13 20:00:46 -05:00

@BlackDex commented on GitHub (Jul 26, 2025):

Also, This has a bit of a relation to #4693 i think.

@BlackDex commented on GitHub (Jul 26, 2025): Also, This has a bit of a relation to #4693 i think.

GiteaMirror commented

2026-07-13 20:00:47 -05:00

@h0m3 commented on GitHub (Jun 13, 2026):

I had this same situation when logging in with my account,

My email provider was slow without me knowing and I was getting timed out while trying to login from a new device. I didn't found aynthing on any logs and then I've rebuilt the whole database, created a new user and found this issue where the email was actually making the user creation process impossible and even the vault login process impossible.

@h0m3 commented on GitHub (Jun 13, 2026): I had this same situation when logging in with my account, My email provider was slow without me knowing and I was getting timed out while trying to login from a new device. I didn't found aynthing on any logs and then I've rebuilt the whole database, created a new user and found this issue where the email was actually making the user creation process impossible and even the vault login process impossible.

GiteaMirror commented

2026-07-13 20:00:47 -05:00

@jack9603301 commented on GitHub (Jun 13, 2026):

@h0m3 Perhaps this is just a suggestion, but have you ever considered building
your own email service? All you need is a server (supporting port 25 and
PTR resolution) and a domain name, or you can purchase a domain email
service from a reputable company. This way, there will be no slow email
speeds; emails will arrive directly on your server--through internal
forwarding.

@jack9603301 commented on GitHub (Jun 13, 2026): @h0m3 Perhaps this is just a suggestion, but have you ever considered building your own email service? All you need is a server (supporting port 25 and PTR resolution) and a domain name, or you can purchase a domain email service from a reputable company. This way, there will be no slow email speeds; emails will arrive directly on your server--through internal forwarding.

GiteaMirror commented

2026-07-13 20:00:48 -05:00

@h0m3 commented on GitHub (Jun 14, 2026):

@h0m3 Perhaps this is just a suggestion, but have you ever considered building
your own email service? All you need is a server (supporting port 25 and
PTR resolution) and a domain name, or you can purchase a domain email
service from a reputable company. This way, there will be no slow email
speeds; emails will arrive directly on your server--through internal
forwarding.

Honestly im not ready to roll my own email for a homelab hahaha. If something ive learned is that if you want to self host something one thing you dont is email.

I could add a local SMTP forwarder and it would solve the issue. But thats just a workaround. Until i add this SMTP forwarder i just disabled email since i only use it for notifications.

I already have a domain email service provider from a very reputable company, but the service is not located at my local network while vaultwarden is so networking issues are rare but possible.

@h0m3 commented on GitHub (Jun 14, 2026): > [@h0m3](https://github.com/h0m3) Perhaps this is just a suggestion, but have you ever considered building > your own email service? All you need is a server (supporting port 25 and > PTR resolution) and a domain name, or you can purchase a domain email > service from a reputable company. This way, there will be no slow email > speeds; emails will arrive directly on your server--through internal > forwarding. Honestly im not ready to roll my own email for a homelab hahaha. If something ive learned is that if you want to self host something one thing you dont is email. I could add a local SMTP forwarder and it would solve the issue. But thats just a workaround. Until i add this SMTP forwarder i just disabled email since i only use it for notifications. I already have a domain email service provider from a very reputable company, but the service is not located at my local network while vaultwarden is so networking issues are rare but possible.

GiteaMirror commented

2026-07-13 20:00:48 -05:00

@mattpr commented on GitHub (Jun 16, 2026):

Perhaps this is just a suggestion, but have you ever considered building
your own email service?

This is not a solution. There are many reasons outgoing SMTP might be slow from time to time (milters that require an external API, etc). For the record, the slow SMTP that resulted in this ticket is self-hosted. Yes it is slow for reasonable reasons that I fully understand and have intentionally configured.

UI process blocking rendering/responsiveness due to waiting for potentially slow external processes is always a UX no-no.

There are other ways to do this if you don't want them to login until you have sent the email. e.g. "We don't recognize this device, please check your email inbox and click the link to confirm this signin.". This screen can be put up immediately and the user knows they have to wait for the email.

The thing is...waiting to send the email because you want to MAKE SURE you sent the email successfully is a fool's errand. The receiving server may happily accept the SMTP submission and bounce it later for policy reasons. So there is really no benefit to blocking in ANY case. Errors (at SMTP time...bounce handling is more complex and not handled by vaultwarden) should of course be logged/alerted to vaultwarden admin (via UI if email isn't working).

If the confirming receipt of the email isn't required (ie isn't blocking them from signing in), then there is no reason for the sending of the email to block the UI rendering thread.

@mattpr commented on GitHub (Jun 16, 2026): > Perhaps this is just a suggestion, but have you ever considered building your own email service? This is not a solution. There are many reasons outgoing SMTP might be slow from time to time (milters that require an external API, etc). For the record, the slow SMTP that resulted in this ticket is self-hosted. Yes it is slow for reasonable reasons that I fully understand and have intentionally configured. UI process blocking rendering/responsiveness due to waiting for potentially slow external processes is always a UX no-no. There are other ways to do this if you don't want them to login until you have sent the email. e.g. "We don't recognize this device, please check your email inbox and click the link to confirm this signin.". This screen can be put up immediately and the user knows they have to wait for the email. The thing is...waiting to send the email because you want to MAKE SURE you sent the email successfully is a fool's errand. The receiving server may happily accept the SMTP submission and bounce it later for policy reasons. So there is really no benefit to blocking in ANY case. Errors (at SMTP time...bounce handling is more complex and not handled by vaultwarden) should of course be logged/alerted to vaultwarden admin (via UI if email isn't working). If the confirming receipt of the email isn't required (ie isn't blocking them from signing in), then there is no reason for the sending of the email to block the UI rendering thread.

GiteaMirror commented

2026-07-13 20:00:48 -05:00

@jack9603301 commented on GitHub (Jun 17, 2026):

@h0m3 Perhaps this is just a suggestion, but have you ever considered building
your own email service? All you need is a server (supporting port 25 and
PTR resolution) and a domain name, or you can purchase a domain email
service from a reputable company. This way, there will be no slow email
speeds; emails will arrive directly on your server--through internal
forwarding.

Honestly im not ready to roll my own email for a homelab hahaha. If something ive learned is that if you want to self host something one thing you dont is email.

I could add a local SMTP forwarder and it would solve the issue. But thats just a workaround. Until i add this SMTP forwarder i just disabled email since i only use it for notifications.

I already have a domain email service provider from a very reputable company, but the service is not located at my local network while vaultwarden is so networking issues are rare but possible.

I have my own email server, which is located in CA, and it's a very low-cost server, and from my own test box experience, it almost never has a serious email delay, and once the email is sent out correctly, it can be received in a very short time (I mean sent externally), and for internal forwarding, it can be received in a very short time. Its latency is almost negligible, but when I refresh the mailbox page, my mail has almost arrived and there has never been a problem.

@jack9603301 commented on GitHub (Jun 17, 2026): > > [@h0m3](https://github.com/h0m3) Perhaps this is just a suggestion, but have you ever considered building > > your own email service? All you need is a server (supporting port 25 and > > PTR resolution) and a domain name, or you can purchase a domain email > > service from a reputable company. This way, there will be no slow email > > speeds; emails will arrive directly on your server--through internal > > forwarding. > > Honestly im not ready to roll my own email for a homelab hahaha. If something ive learned is that if you want to self host something one thing you dont is email. > > I could add a local SMTP forwarder and it would solve the issue. But thats just a workaround. Until i add this SMTP forwarder i just disabled email since i only use it for notifications. > > I already have a domain email service provider from a very reputable company, but the service is not located at my local network while vaultwarden is so networking issues are rare but possible. I have my own email server, which is located in CA, and it's a very low-cost server, and from my own test box experience, it almost never has a serious email delay, and once the email is sent out correctly, it can be received in a very short time (I mean sent externally), and for internal forwarding, it can be received in a very short time. Its latency is almost negligible, but when I refresh the mailbox page, my mail has almost arrived and there has never been a problem.

GiteaMirror commented

2026-07-13 20:00:49 -05:00

@jack9603301 commented on GitHub (Jun 17, 2026):

Perhaps this is just a suggestion, but have you ever considered building
your own email service?

This is not a solution. There are many reasons outgoing SMTP might be slow from time to time (milters that require an external API, etc). For the record, the slow SMTP that resulted in this ticket is self-hosted. Yes it is slow for reasonable reasons that I fully understand and have intentionally configured.

Please see my last reply. I have my own email address and link it to my own email address. Seriously, my email address is in CA. It almost never has a problem with external mail being delayed. When I refresh my inbox, the mail I want arrives almost immediately. I also use it as a forwarder for outlook mail, and for internal forwarding (self-forwarding), it has almost no latency, so it's a solution. If your email system provider is experiencing severe delays, you need to get in touch with them

@jack9603301 commented on GitHub (Jun 17, 2026): > > Perhaps this is just a suggestion, but have you ever considered building > your own email service? > > This is not a solution. There are many reasons outgoing SMTP might be slow from time to time (milters that require an external API, etc). For the record, the slow SMTP that resulted in this ticket is self-hosted. Yes it is slow for reasonable reasons that I fully understand and have intentionally configured. > Please see my last reply. I have my own email address and link it to my own email address. Seriously, my email address is in CA. It almost never has a problem with external mail being delayed. When I refresh my inbox, the mail I want arrives almost immediately. I also use it as a forwarder for outlook mail, and for internal forwarding (self-forwarding), it has almost no latency, so it's a solution. If your email system provider is experiencing severe delays, you need to get in touch with them

GiteaMirror commented

2026-07-13 20:00:49 -05:00

@mattpr commented on GitHub (Jun 17, 2026):

from my own test box experience
It almost never has a problem with external mail being delayed

Hi Jack. The issue is different. This isn't external email. It is internal SMTP connection for outgoing transactional email blocking the UI thread on vaultwarden.

There are many good reasons why an SMTP service may not accept email quickly. There may be some number of checks that are run prior to accepting SMTP submission...even if it is an authenticated SMTP connection (authenticated accounts at many email services are often abused for spamming). The time taken for those checks should not always be slow...but can be. They may rely on external services/APIs that may slow down from time to time or even have outages where there is a delay until a timeout happens from the milter in which case some default approve/deny will happen.

Bottom line is what I said earlier. Sending the email should not block the UI thread. Counting on your SMTP server to be "fast enough" to not create a sh**tty user experience on the UI side is poor design.

I also run my own email servers since many years. SMTP acceptance can be slow for good and well understood reasons (milters that rely on external APIs that can be slow sometimes). For normal email, this is perfectly acceptable because the message sits in the outbox while the email client waits for it to be accepted or not. No user sitting around waiting for the outbox to clear. Imagine if every time you sent an email, your computer froze until the email was actually accepted by the SMTP server rather than just putting it into the outbox and sending it in the background.

@mattpr commented on GitHub (Jun 17, 2026): > from my own test box experience > It almost never has a problem with external mail being delayed Hi Jack. The issue is different. This isn't external email. It is internal SMTP connection for outgoing transactional email blocking the UI thread on vaultwarden. There are many good reasons why an SMTP service may not accept email quickly. There may be some number of checks that are run prior to accepting SMTP submission...even if it is an authenticated SMTP connection (authenticated accounts at many email services are often abused for spamming). The time taken for those checks should not always be slow...but can be. They may rely on external services/APIs that may slow down from time to time or even have outages where there is a delay until a timeout happens from the milter in which case some default approve/deny will happen. Bottom line is what I said earlier. Sending the email should not block the UI thread. Counting on your SMTP server to be "fast enough" to not create a sh**tty user experience on the UI side is poor design. I also run my own email servers since many years. SMTP acceptance can be slow for good and well understood reasons (milters that rely on external APIs that can be slow sometimes). For normal email, this is perfectly acceptable because the message sits in the outbox while the email client waits for it to be accepted or not. No user sitting around waiting for the outbox to clear. Imagine if every time you sent an email, your computer froze until the email was actually accepted by the SMTP server rather than just putting it into the outbox and sending it in the background.

GiteaMirror commented

2026-07-13 20:00:49 -05:00

@jack9603301 commented on GitHub (Jun 17, 2026):

from my own test box experience
It almost never has a problem with external mail being delayed

Hi Jack. The issue is different. This isn't external email. It is internal SMTP connection for outgoing transactional email blocking the UI thread on vaultwarden.

There are many good reasons why an SMTP service may not accept email quickly. There may be some number of checks that are run prior to accepting SMTP submission...even if it is an authenticated SMTP connection (authenticated accounts at many email services are often abused for spamming). The time taken for those checks should not always be slow...but can be. They may rely on external services/APIs that may slow down from time to time or even have outages where there is a delay until a timeout happens from the milter in which case some default approve/deny will happen.

Bottom line is what I said earlier. Sending the email should not block the UI thread. Counting on your SMTP server to be "fast enough" to not create a sh**tty user experience on the UI side is poor design.

I also run my own email servers since many years. SMTP acceptance can be slow for good and well understood reasons (milters that rely on external APIs that can be slow sometimes). For normal email, this is perfectly acceptable because the message sits in the outbox while the email client waits for it to be accepted or not. No user sitting around waiting for the outbox to clear. Imagine if every time you sent an email, your computer froze until the email was actually accepted by the SMTP server rather than just putting it into the outbox and sending it in the background.

You have a point, but I use self-retweeting a lot, as do services such as wordpress and vaultwarden, and I don't find any obvious problems with the self-retweeting process. Of course, I use the postfix solution and don't have a spam policy

@jack9603301 commented on GitHub (Jun 17, 2026): > > from my own test box experience > > It almost never has a problem with external mail being delayed > > Hi Jack. The issue is different. This isn't external email. It is internal SMTP connection for outgoing transactional email blocking the UI thread on vaultwarden. > > There are many good reasons why an SMTP service may not accept email quickly. There may be some number of checks that are run prior to accepting SMTP submission...even if it is an authenticated SMTP connection (authenticated accounts at many email services are often abused for spamming). The time taken for those checks should not always be slow...but can be. They may rely on external services/APIs that may slow down from time to time or even have outages where there is a delay until a timeout happens from the milter in which case some default approve/deny will happen. > > Bottom line is what I said earlier. Sending the email should not block the UI thread. Counting on your SMTP server to be "fast enough" to not create a sh**tty user experience on the UI side is poor design. > > I also run my own email servers since many years. SMTP acceptance can be slow for good and well understood reasons (milters that rely on external APIs that can be slow sometimes). For normal email, this is perfectly acceptable because the message sits in the outbox while the email client waits for it to be accepted or not. No user sitting around waiting for the outbox to clear. Imagine if every time you sent an email, your computer froze until the email was actually accepted by the SMTP server rather than just putting it into the outbox and sending it in the background. You have a point, but I use self-retweeting a lot, as do services such as wordpress and vaultwarden, and I don't find any obvious problems with the self-retweeting process. Of course, I use the postfix solution and don't have a spam policy

GiteaMirror commented

2026-07-13 20:00:50 -05:00

@jack9603301 commented on GitHub (Jun 17, 2026):

from my own test box experience
It almost never has a problem with external mail being delayed

Hi Jack. The issue is different. This isn't external email. It is internal SMTP connection for outgoing transactional email blocking the UI thread on vaultwarden.

There are many good reasons why an SMTP service may not accept email quickly. There may be some number of checks that are run prior to accepting SMTP submission...even if it is an authenticated SMTP connection (authenticated accounts at many email services are often abused for spamming). The time taken for those checks should not always be slow...but can be. They may rely on external services/APIs that may slow down from time to time or even have outages where there is a delay until a timeout happens from the milter in which case some default approve/deny will happen.

Bottom line is what I said earlier. Sending the email should not block the UI thread. Counting on your SMTP server to be "fast enough" to not create a sh**tty user experience on the UI side is poor design.

I also run my own email servers since many years. SMTP acceptance can be slow for good and well understood reasons (milters that rely on external APIs that can be slow sometimes). For normal email, this is perfectly acceptable because the message sits in the outbox while the email client waits for it to be accepted or not. No user sitting around waiting for the outbox to clear. Imagine if every time you sent an email, your computer froze until the email was actually accepted by the SMTP server rather than just putting it into the outbox and sending it in the background.

One possibility is that there is a problem with the design of vaultwarden, sending mail takes time, and the UI should never be blocked

However, the time for self-retweeting is negligible, and I don't know why it causes obvious problems.

@jack9603301 commented on GitHub (Jun 17, 2026): > > from my own test box experience > > It almost never has a problem with external mail being delayed > > Hi Jack. The issue is different. This isn't external email. It is internal SMTP connection for outgoing transactional email blocking the UI thread on vaultwarden. > > There are many good reasons why an SMTP service may not accept email quickly. There may be some number of checks that are run prior to accepting SMTP submission...even if it is an authenticated SMTP connection (authenticated accounts at many email services are often abused for spamming). The time taken for those checks should not always be slow...but can be. They may rely on external services/APIs that may slow down from time to time or even have outages where there is a delay until a timeout happens from the milter in which case some default approve/deny will happen. > > Bottom line is what I said earlier. Sending the email should not block the UI thread. Counting on your SMTP server to be "fast enough" to not create a sh**tty user experience on the UI side is poor design. > > I also run my own email servers since many years. SMTP acceptance can be slow for good and well understood reasons (milters that rely on external APIs that can be slow sometimes). For normal email, this is perfectly acceptable because the message sits in the outbox while the email client waits for it to be accepted or not. No user sitting around waiting for the outbox to clear. Imagine if every time you sent an email, your computer froze until the email was actually accepted by the SMTP server rather than just putting it into the outbox and sending it in the background. One possibility is that there is a problem with the design of vaultwarden, sending mail takes time, and the UI should never be blocked However, the time for self-retweeting is negligible, and I don't know why it causes obvious problems.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#35216