Cloudron Forum

@robi In assumption that there is already at least one domain, the code to add a mailbox for a user is already there --> API documentation of Cloudron. To implement such feature you would need a checkbox like "create email address", a drop down menu that lists all domains (with mailserver enabled?) and a field for the inbox name.

@smhick said in Bulk changes to default email addresses: The default email is shortname@domain.com Says who? I think you are misunderstanding something here. The email address is whatever you create within the Email Server of Cloudron. First you need to setup an email address at Cloudrons Email Server and assign it to a user. Lets say you create an Email address within Cloudron for our user "bob" with the display name "Bob Marley" that goes like "bob.marley@domain.com". Now you login to SOGo with the credentials bob.marley@domain.com and the password of bob. So to be clear: You are in charge of creating firstname.lastname@domain.com in the first place before apps like SOGo and other clients come into play.

@girish said in Domains and existing email configuration: It is possible to setup Cloudron to receive emails on a subdomain though (like email.example.com). For this, add email.example.com in Domains as well and then you can enable incoming mail for that domain. This is exactly what I was looking for. I didn't know I had to add that additional email.example.com to the list of domains configured in my Cloudron instance. Thanks a ton.

@girish Oh, never mind, it was an SMTP OUT block by the VPS provider... I didn't think that it would apply to running email from another server through OpenVPN on this one... Sorry for taking your time with this, and thanks again.

@hustler PTR in your case is about setting a reverse DNS (rDNS) record. Take a look at the Linode tutorial: https://www.linode.com/docs/guides/configure-your-linode-for-reverse-dns/

@girish as you know we use an external Mail Proxy, imapsieve is a good tool to get spam/ham feedback from our users. Second, it can be used to automate flow based on where the mail has been moved by the user.

@d19dotca I'm excited by the potential for https://ntfy.sh. Maybe a cloudron official instance which sets up channels for all customers, so cloudron-generated notifications can be delivered to a customer. Or maybe there's a better way. I just think ntfy.sh is so easy to implement into scripts.

@girish Yes I did! Thanks for all your help!

Closed due to inactivity

@qwinter Yep, I understood that. But, what DNS settings in the end worked?

@TechoutDev To debug, open the mail logs window. Mail -> Logs button in top right. And then there is another logs button inside it. Keep that browser window open. Then, use the send test mail button - https://docs.cloudron.io/email/#send-test-email . Can you please post what's in the logs?

@scooke Hi, sorry for the delay. Yeah, @girish was able to solve the problem, which was not a technical one, as usually is the case with these things, heh. The email she uses is an alias, and not <username>@<mydomain>, and she hadn't used it in a while. We're both pretty sure she used to be able to log in with either username only (no '@domain'), or with her aliased email <alias>@<mydomain>, but it seems we're both wrong on this. So I tried to log into her email with <username>@<mydomain> and, lo and behold, it worked. She doesn't use this email at all, so I'm talking to her and seeing if we change her username, since there's only a few apps and email will be the most important one from now on. Thanks everyone for the help!

@msbt It's intentional that only superadmins can see it. It won't be good for privacy if an admin could see all the emails being sent. It's OK for superadmins to see this because it's assumed they have SSH access. I have added a note in https://docs.cloudron.io/email/#event-log and fixed the UI to hide the button for non-superadmins.

@jdaviescoates Yes, cron not working is a symptom of docker not working (stuck in configuring)

@savity Indeed, there is no event log entry, I will add it.

@m-si Sweet! Thanks a lot for sharing this workaround. It works perfectly and helps me to cover the time until true MTA-STS + DANE support from Cloudron. E-Mail reputation is really crucial these days. Just one remark for other readers: If you are doing this for the first time, you should probably start with mode: testing. Once you have successfully established MTA-STS (no errors), you should change to "mode: enforce" and increase the max_age value. Many senders expect it to be at least several weeks.

Oh cool thanks for pointing that out, I hadn't noticed before. I guess the downsides don't really apply to me right now, but I'm not sure I'd want to enable arbitrary masquerading if there were a bunch of other people on this cloudron. I still think it's reasonable for users to be able to send with a subaddress of any of their aliases, without opening the floodgates and allowing them to send from any address at all.

@WiseMetalhead yep, that's exactly what I was looking for, thanks! I thought I typically keep up with recent posts on the forums but somehow missed that one. Looks like all is well and will be resolved with the next Cloudron release!

Strange indeed, but I blocked the VPS Port 25. Whilst blocked, I restarted Kuma and Tiny but to no avail. All up and running now with 25 unblocked.