Accessing email mailbox owned by a group
-
Ah, I see now. I misremembered that we removed the legacy behavior. But apparently, it is still there - https://git.cloudron.io/apps/roundcube-app/-/blob/master/config.inc.php?ref_type=heads#L8 . If you don't provide a domain and just use the username, it defaults to the email domain. I wouldn't rely on this behavior in the long run (though, we won't remove it at this point, unless it conflicts with some other feature)!
-
@girish I see, thanks.
Can I just ask a couple of clarifications:
- When you say username, do you mean prefix of the email address (the part before the @ in the email address) or the Cloudron username?
- when you say the email domain, do you mean the global email domain (MX domain), or the domain on which the email app installed?
I think the current behaviour actually makes sense and is quite convenient to login rather than having to enter the full email address every time. I think it would make most sense and be the least confusing if the username to login is the prefix of the email address, and that it default to the domain of the email app rather than the global email domain. I think that way would be a very neat approach, yet still giving the flexibility to login on any email app installed on the Cloudron using the full email address for niche use cases.
-
@avatar1024 quite a long time ago, Cloudron used to create mailboxes named
username@domain.com
when you create a username. Later, the platform grew to support multiple domains (should we now create username@ in every domain?) and arbitrary mailboxes (who can have arbitrary users as owners).With that in mind, yes, username means the prefix before
@
. The email domain is the app's installation domain.Let's say a username has 3 mailboxes -
admin@
,support@
andusername@
. Which mailbox is seen when logged in? You might say username@ but what if username@ is not in that list?In the end, we are much limited by what the apps can do. Most apps cannot show multiple mailboxes with a single auth. They also do not support mappings from username to mailbox name. This is why we decided to keep it simple (for oureslves) and just make users login with mailbox name. Atleast, all email apps support this.
-
@girish said in Accessing email mailbox owned by a group:
Let's say a username has 3 mailboxes - admin@, support@ and username@ . Which mailbox is seen when logged in? You might say username@ but what if username@ is not in that list?
@girish I think we keep misunderstanding each other here. I know how it used to be back in the day and I also know that for ages now Cloudron has been using the full email address as username to log into emails exactly because of the confusion you've just pointed at with the above example. So I'm with you here.
What I'm pointing out is that if using the email prefix as username to login (and NOT the Cloudron username) then we get around the confusion in your example. So if a user is the owner of three mailboxes - admin@, support@ and username@, then to log in each other them the username would simply be "admin", "support" and "username" respectively, and the password is the user password. I'm not taking about showing multiple mailboxes at once or anything like that. With a single domain this works, there is no confusion and yet we don't need to write the full email address every time but only the prefix which is easy. And this is what seems to be happening in
Roundcubeall webmail apps (edit) right now in Cloudron.Now this gets confusing with multiple domains becasue a single user can be the owner of say admin@domain1.coop and admin@domain2.coop. But for this "I humbly think" the default behaviour I described in my previous message intuitively solves this issue, that is:
- if a user enters only the prefix then the @domain defaults to the domain the webmail app is installed on. So say if Snappymail is installed at webmail.domain1.coop and I enter "admin" as a username to login, then it default to the mailbox admin@domain1.coop.
- if a user enters the full email address as the username to login then they/she/he can access that mailbox no matter what the domain of webmail app is.
Here is what I wrote in my previous message:
I think it would make most sense and be the least confusing if the username to login is the prefix of the email address, and that it default to the domain of the email app rather than the global email domain. I think that way would be a very neat approach, yet still giving the flexibility to login on any email app installed on the Cloudron using the full email address for niche use cases.
-
@girish I tested with all other webmail apps (Snappy, Roundcube and SoGo), and just entering the prefix works to log into the mailboxes, no need for the full email address right now.
-
@avatar1024 said in Accessing email mailbox owned by a group:
no need for the full email address right now.
But that only works if the email address and the email app have matching domains though, right? (at least that's what I worked out when testing).
-
@jdaviescoates Yes that's correct. It actually works exactly as desired from my point of you that is: use only prefix as the username and then it defaults to mailbox prefix@domainofthewebmailapp.
-
@girish said in Accessing email mailbox owned by a group:
quite a long time ago, Cloudron used to create mailboxes named
username@domain.com
when you create a username.Also unrelated but did anyone here ever automate this? Because that's a behavior I'd like to mimic because I'm only using one tld
-
@avatar1024 said in Accessing email mailbox owned by a group:
@jdaviescoates Yes that's correct. It actually works exactly as desired from my point of you that is: use only prefix as the username and then it defaults to mailbox prefix@domainofthewebmailapp.
@girish so do we know if the current behaviour is intended / something that is going to last (which I hope) as I'm writing guidance for an org on how to use their webmail?
Happy 2025 to Cloudron and to all of you who make it possible
-
@avatar1024 We won't break it intentionally but this only works because the mail clients have the concept of a default domain. Since those apps haven't changed forever and neither have the cloudron packages (wrt this behavior), I think you can safely conclude this will continue working.