@BrutalBirdie So I figured this out, and it's definitely NOT a Cloudron issue. Actually, it's a Thunderbird issue... so I'll probably go write a quick report on Bugzilla at some point.

It turns out that when you hook up two emails for Thunderbird that (1) go the same mail server and (2) share the same password, that causes Thunderbird to ignore the username.

What this means:

Let's say you set up two mailboxes in Cloudron, your.name@company.com and service@company.com. While your.name@company.com is accessible to you, service@company.com is instead accessible to a group you are a part of. You can use user account password to log into both.

Let's say you first add your.name@compay.com to Thunderbird. It will work fine. However when you add service@company.com, outgoing will be messed up (though incoming will work). Rather than outgoing being registered for service@company.com, it'll go out through your.name@company.com, which is not the correct behavior.

You can fix this by going into Outgoing Servers in Thunderbird, but it's a big pain it doesn't need to be, and I'm sure it's something that can be fixed on the Thunderbird end.

Anyways, that was a fun dive into some email issues... hopefully I can get this fixed and jump back into using groups, as that helps make security issues with emails a little easier to deal with (no having to reset everybody's shared password).

Hope you all have an awesome day!

@girish
The problem seems to be that on "Server A" I have to enable mailservices for the domain in question. Then when I try to send mail from Server B the

server B produces an error

{ "ts": 1663009665363, "type": "deferred", "direction": "outbound", "uuid": "B17FA8D4-5997-4FE6-8636-400140195457.1", "messageId": null, "mailFrom": "<>", "spamStatus": null, "rcptTo": [ "<no-reply@serverB.com>" ], "message": "Tried all MXs", "delay": 8192 }

and server A produces the error

{ "ts": 1663009909718, "type": "bounce", "direction": "outbound", "uuid": "380CB958-8DD9-45DC-B9C3-13F89C1FD866.1.1", "messageId": "<f993a729-8533-909f-f3d0-be386c19df96@draglabs.com>", "mailFrom": "<no-reply@draglabs.com>", "spamStatus": null, "rcptTo": [ "<user@serverB.com>" ], "message": "Some recipients failed: <user@serverB.com>", "mx": { "priority": 0, "exchange": "127.0.0.1", "port": 2424, "using_lmtp": true, "family": "A", "bind_helo": "my.draglabs.com" }, "bounced_rcpt": [ { "original": "<user@serverB.com>", "original_host": "serverB.com", "host": "serverB.com", "user": "user", "reason": "550 5.1.1 <user@serverB.com> User doesn't exist: user@serverB.com", "dsn_action": "failed", "dsn_smtp_code": "550", "dsn_smtp_extc": "5.1.1", "dsn_status": "5.1.1", "dsn_smtp_response": "<user@serverB.com> User doesn't exist: user@serverB.com", "dsn_remote_mta": "127.0.0.1" } ] }

What I think is happening is that because I enabled email on Server A, Server A is automatically looking for that user's email inbox to drop the email as opposed to routing it though the internet where is would use the MX records listed in the DNS.

So the question becomes how do you log into an email server without enabling inbound email.

Or how do you convince cloudron to be happy sending email from a different subdomain? like mail.serverb.com without setting the root of server be to my.mail.serverb.com

yes confirmed

I did some tests and they way it is configured now I can email anyone other than <user>@DomainB.com and if I disable "Incoming Email" then the server A user "relay@serverB.com" cannot authenticate for the purpose of sending emails.

@subven @girish - Any Ideas on a solution here?

@foliovision Cloudron should create the DKIM records if you're using the DO API for your domains. Cloudron does not delete existing records so if you add something in manually, rest assured it won't get wiped by Cloudron.

https://docs.cloudron.io/email/#dkim

BTW, if you go to your Cloudron dashboard --> Email --> Status --> and click on "Redo DNS Setup", that should add in the required records. It should be listed as a TXT record in DO's DNS.

Example:

TXT cloudron._domainkey "v=DKIM1; t=s; p=TIDfKL7GCS...

@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!

I think you're looking for more of a mail relay setup with archival things done for incoming emails.

@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?

It would be neat if the full text search could be extended to all hosted static sites.

@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.

OK thanks @girish.

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

That suggestion in turn came from https://forum.cloudron.io/topic/2315/cloudron-email-feature-improvements-ideas

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!

Is anybody try one of these delisting process ??

https://sender.office.com

This one seams to be specifically for live.com and ...

https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75

https://sendersupport.olc.protection.outlook.com/snds/index.aspx

I did the 2 first one, the first is pretty quick you receive an email and validate if the IP of your server is in their internal block list,
the second is a form is a little bit more elaborate they ask for error message and if you have a website related to that domain.

I will move this to Feature request then.

@mehdi 😳 good catch, will fix!

@jdaviescoates ah yes then this most likely was the issue with the unbound anchor file. See https://docs.cloudron.io/troubleshooting/#recovery-after-disk-full

@girish
Unfortunately, I don't know how to find out... but I'll keep an eye on it and update when I find out! Thanks!

@girish Much appreciated, thank you!

@girish Thanks for a quick fix, It's now working

We didn't get to the bottom of this but the user solved it by moving to sendgrid.