Due to compliance requirements I cannot enable email on our cloudron instance and so the domain that was configured is set to disabled:
I have several bitwarden users setup but they were all setup and their email addresses verified before the domain was disabled.
I have created a new cloudron user and then created a new bitwarden user by opening the bitwarden app as the new cloudron user and selecting Create Account on the bitwarden login screen.
The user can now log in to bitwarden but after logging in they see the orange Verify Email box in the top right indicating that they need to verify their email address to unlock all features.
I have accessed the vaultwarden admin panel and can see that this user doesn't have the green verified label whereaas all the other users I have do.
How do I get this user verified/turn on the verified flag so that the user has full functionality without enabling email on our cloudron server?
@ChristopherMag just to be sure, sending out emails on a domain is usually still possible to be supported, even if the receiving/mailbox side is disabled. Only sending is also the default on Cloudron. I am just mentioning that, since nearly all apps eventually require sending out emails for various reasons and just wanted to make sure the distinction of purely sending and a whole email solution is known.
@robi Clicking either of these two buttons under the Actions heading does not show the link that was sent:
I think your referring to the ability to see emails that pass through cloudron and so if bitwarden had generated an email you would be able to view it but when incoming email is disabled in cloudron then the SMTP server configuration that gets pushed into the apps points to a smtp server that doesn't respond so no email is even generated by bitwarden.
Due to compliance requirements I cannot enable email on our cloudron instance
I'm puzzled as to what requirements would prevent outbound only email.
@roundhouse1924 As an example we use Wekan and it sends email notifications when a card has been moved and includes the title of the card that was moved.
That title might contain personally identifiable information about a client and so cannot be sent out via email.
In theory apps like Wekan can be configured to restrict what it sends or sanitize it but I have experienced issues where some code path incorrectly sent out an email even though it shouldn't.
The easiest we to prevent that from happening seemed to be setting the Email Relay to disable:
If it was possible to only allow outbound email for bitwarden that would probably be ok.
@nebulon Maybe I didn't word this well.
We have Outbound email set to disabled.
With this setting when apps try to make an SMTP connection to send email to the mail server that Cloudron specified the app use it fails to make the smtp connection.
If it was possible for the Cloudron SMTP server to receive Outbound destined email from apps but then never actually send it on that would allow us to go in and pull out the emails that we need like those generated by bitwarden.
Here is a more clear example a specific issue I am hitting that I believe is the the same root cause, outgoing email being disabled which internally disables the cloudron smtp server.
If I add a user to a Bitwarden Organization it tries to send them an email and fails with the following:
This currently is preventing me from sharing the passwords we use within that organization with this new user.
@nebulon can you please mark this issue solved?
To resolve this I did the following:
- Installed smtp4dev on another computer on the network
- Configured Cloudron with the External SMTP Server (No Authentication) Email relay option
- Put in the ip address of the system running smtp4dev
After that I could view the emails being sent by bitwarden in the smtp4dev web interface and then open the "verify email address" and "join organization" links bitwarden sent out via email so that the user is fully setup in bitwarden and then finally confirm the user's joining the organization in bitwarden as that also requires an email to be able to be sent to complete.
I have now set Email Relay back to disable and will repeat these steps when needing to add new users's in the future.
@nebulon If it was possible to get "raw mail data or mail event logs from the Cloudron mail server" with Outbound > Email Relay, Disabled configured it would really help out in situations like this as I would prefer not to have to take the steps I did.
In case anyone is looking at this later, the SMTP server that Cloudron configures apps to use will not respond to any connections from those apps (as evidenced by the error messages above in this thread) when Email Relay is set to Disabled.
It would be nice if when Email Relay was set to Disabled the internal Cloudron mail server still received the email from the app and just didn't forward it anywhere but that is not the current behavior.
@christophermag The email server currently does not store raw email. This is probably quite a bit of work! But the mail server actually does have a way to log raw emails. Maybe that's sufficient? We should have something to have verbose logs in the next release as part of the various email improvements.