Is there a way to create email addresses without creating Cloudron users?
-
-
-
-
@girish Yes, the idea is that I, the admin, install some sort of email app (like sogo, I guess), and then be able to create and assign an email address and password to a user. This user uses the email address just for email; they don't need access or any other presence on Cloudron. They can also use an email client to receive and send email. Basically what the email option does already, minus the integration with Cloudron directly.
I was fiddling around with poste.io and miab, and within those I can create any number of email addresses, and the users, for the most part, know and only want to/need to know what their email login info is (plus the mail server info so they can use Apple Mail or whatever).
Thank you.
(Let me add that if this is not possible due to something like security, or the need to generate income for the company, that is fine by me. I am just wondering if there is a way to do this, not that cloudron "has" to do this. EDIT: It seems like that feature request, per mailbox password, would along the same lines as what I'm asking here.) -
-
@mehdi Thanks for response... except this creates a Cloudron user account. And from my brief testing, creating a Cloudron user requires their response to the account creation, thereby alerting them to the fact they have a Cloudron account.
I'm basically trying to lower the degree of confusion some users may have about having both a Cloudron account and an email account. If they could just be assigned an email address and a password, that would be smoothest.
-
Hi everyone,
Thank you for the various responses. They prompted me to go over the steps again and I've found a way to achieve my goal.- Start creating a new user, using their Full Name
- For username, use the name that will be used in the email (they've already decided actually)
- Initially, use an email I can access for their email.
- Uncheck the "Send an invitation email now" box (I guess if the email is coming to me I didn't need to uncheck this)
- Assign their role,
User, and Group (the Group seems not so crucial) - Create the user
- Go to the Email panel in the Cloudron, and click on the domain in question
- Create a new mailbox using the username for the User
- Choose the already-made user as the Mailbox Owner
At this point I tried to login to SOGo using what I thought was their password, but it didn't work.
- Go to the User list in Cloudron and
Reset password or invite link for newuser - Receive the email at the previously set address that I can access.
- Click on the link which brings me to a nice Cloudron page (which I'm trying to have the user avoid seeing or interact with) and choose a password, then save the info.
- Go back to SOGo to try signing in again, and it works!
- Send the user their username and login for email only.
One big weakness with this is, if they forget their password (and they always do), SOGo doesn't have a way to reset it, so, they will have to contact me to help them. I assume they may not mind if I do the steps above (7-9) and send them a new password (all they will know is they have a new password), but the security-minded among them will think , 'Hmm, scooke knows my password, will he log in to my email?" So, they very well might end up on a Cloudron dashboard, wondering what the heck it is!
Hmmm. I might need to just go to MXRoute, OR, just tell them that the Cloudron dashboard they see is "the system" with the SOGo app visible to them. They could very well start thinking that they need to sign in there in order to get to webmail!
EDIT: I have done all the above, and realized that the user can in fact sign into the web app SOGo without SOGo being visible on the Cloudron dashboard of the user. However, if I make it so no apps are visible, then the following text is displayed:
You don't have access to any apps yet! Once you do, they will show up here.So, I would need to make the SOGo app visible to them in the Cloudron dashboard, which will only be discovered if they ever have to reset their password.
-
-
@msbt I agree. In this case though there is no other way to do this unless they sign up or register themselves on the Cloudron. I suppose I could get this to work with minimal confusion. I think I'd need to set up the mailbox ahead of time too so that once they've finished their Cloudron account (with their own password) they can directly login. This also depends on them using the same username as the one I used for the mailbox.
OR I just wait until they've finished setting up their Cloudron account, see what they used for their account name, and THEN make the mailbox, hoping that in the meantime they don't try to login to SOGO, fail, and then think this all sucks. To mitigate against that I guess I could only make the SOGo app visible in their Cloudron dashboard after I've see what their username is, make the mailbox, then make SOGo visible to them, but not really mention the Cloudron dashboard again, telling them instead they can use webmail at such-and-such url.
However, they will have signed up on the Cloudron with their current email, possible making them wonder why they are getting a different email a few minutes later.
Hm, I don't think there is anyway around this other than just going with an outside email provider, like MXRoute. (The point being it is important that they have just one login to worry about - the email, and not the email AND the Cloudron ((even though they are the same)).
-
-
@msbt I'm not following you here. What is the "them" in your reply? Is it the account (the Cloudron account), or the email address made in the Cloudron?
you can link accounts to email addresses as soon as you created **them**I need to wait for them to register with Cloudron in order to find out what their username is, because their username will be the front part of the email address of the domain. (There is one domain for this Cloudron.)
I could guess their username and and go ahead and use it to create the email and then assign their Cloudron user as MailBox Owner, BUT if the usernames differ (remember, they will now have 2 emails, the one they signed up with, and then the Cloudron email) that will be sure to invite confusion and questions.
-
@scooke you can even give your users a predefined username. what you could do: add the users without sending them an invitation, add the emailadresses and link them to their accounts, then hand out the link to your cloudron where they can (re)set their password which will then be used for sogo login. If that's not an option, then I'm out of ideas
About the "them": you can add emailadresses and link them to cloudron accounts, regardless if those accounts are active or not.
-
@scooke if I understand you correctly, the main issue of not setting up a Cloudron account for each user, is the need to use two email addresses then. So since you seem to setup their accounts anyways, you might as well just create them with the same email address and not send out the invite automatically (there is a checkbox on user creation for this). Then you can send them the invite link through other means. This should make sure the email addresses match. You can also set the fallback email to some non-cloudron email for password reset mails.
-
@nebulon Possibly. Let me try explaining again.
I have set up a cloudron on example.com. I have 5 users who will be using new email addresses like user1@example.org. But I have not made those email addresses yet in Cloudron. I in fact did try that, but then realized that the users will need a password to actually use the email address, whether through SOGo or an email client. This led me to realize that the only way for them to have access to the new email address is to also make a User on Cloudron. But, I would like to avoid them interacting with Cloudron more than they need to mainly due to "complication" of them having to deal with two things - their email and this Cloudron thing. But also, if I have them set up their Cloudron account first they will use their current email, user1@current.com. Then, they will have two emails to think about: Their current user1@current.com, and the Cloudron specific user1@example.com
But we are stuck again. I have to use their current email, user1@current.com because there won't be password yet for user1@example.com. I could set it all up as I detailed above, but in order for them to reset their passwords I would have to user the user1@current.com address as the secondary address (in the User info). Then they could, if ever needed, reset their password, and even though it would go to their previous email address (which unfortunately might have been cancelled after some time), they would almost certainly end up interacting with the Cloudron dashboard, wondering what it is.
I don't see anyway around this. I either set it all up for them, including their passwords (and then of course delete these from my records), or I may as well get them to go straight to the User registration and deal with whatever issues and questions they will have about the two/three systems (email/SOGo and Cloudron).
-
@scooke I really think you're making it yourself a little bit too complicated
I manage 4 Cloudron's Premium, of which 3 are for 3 different foundations working with volunteers (average age 65+)
This is my workflow:
- create an account with username: firstname.lastname and with an email address I know. BUT: don't send invitation link! Make it member of the usergroup "webmail" and make sure the "webmail"-app is accessible by that group and the rest of the apps NOT
- create an email account with same name firstname.lastname and the owner is the user in step 1
- go back to the user and change the Primary email into the just created email address in step 2
- copy the invite link and use it in a self composed email
What I do explain to the users:
- "your account for my.domainname.tld is to make use of our fantastic platform and to manage you password"
- "logging in to my.domainname.tld shows you a personal dashboard with all the apps you need"
- "click on My Webmail and log in with your username firstname.lastname and you self created password" (I rename all the LDAP apps to start with My and explain that every such app is accessible with same credentials.
That's it!
