@subven Have you read https://docs.microsoft.com/en-us/office365/securitycompliance/use-the-delist-portal-to-remove-yourself-from-the-office-365-blocked-senders-lis ? You should be able to get your specific IP delisted.

Looks like it was in fact getting sent to the catchall. Thanks everyone for your input.

@ruihildt This is not for deleting emails but for deleting a whole mailbox. If email is deleted, they are gone forever. You can see all the mailboxes under /home/yellowtent/boxdata/mail/vmail.

@d19dotca Thanks for the details! Let us get back by testing it out on a Mac.

I had autoconfig setup for business emails before cloudron. Here is the process I used: Let's say you have the following domains: test.com: The domain for which you want to have email autoconfig my.test.com: The URL of your cloudron server that manages your email and will broadcast the autoconfig configuration. setup DNS entries in the test.com DNS // entry for outlook (never tested since I only use thunderbird) _autodiscover._tcp 600 IN SRV 0 0 443 my.test.com // entry for thunderbird and others autoconfig 600 IN CNAME my.test.com smtp 600 IN CNAME my.test.com imap 600 IN CNAME my.test.com // autoconfig.test.com does not need an SSL certificate // smtp.test.com, imap.test.com must have an active SSL certificate Create the mail directory and autoconfig file in the webroot for autoconfig.test.com create the file mail/config-v1.1.xml Content of mail/config-v1.1.xml // Here is a sample: <?xml version="1.0" encoding="UTF-8"?> <clientConfig version="1.1"> <emailProvider id="my.test.com"> <domain>test.com</domain> <domain>another-domain.com</domain> <displayName>test.com</displayName> <displayShortName>Test</displayShortName> <incomingServer type="imap"> <hostname>imap.test.com</hostname> <port>993</port> <socketType>SSL</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </incomingServer> <outgoingServer type="smtp"> <hostname>smtp.test.com</hostname> <port>587</port> <socketType>STARTTLS</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </outgoingServer> </emailProvider> </clientConfig> Nginx config since autoconfig does not require any SSL certificate you can setup any autoconfig request to match the same config file. For cloudron it might be better to have one config file per domain? server { listen 80; server_name autoconfig.*; root /var/www/autoconfig.test.com; access_log /var/log/nginx/autoconfig.test.com/access.log; error_log /var/log/nginx/autoconfig.test.com/error.log warn; location / { try_files $uri $uri/; } } Aside note in theory you should be able to not use imap.test.com and smtp.test.com, in practice though, I had trouble with thunderbird not recognizing the autoconfig without those 2 domains setup (it was 1 year ago, maybe it changed since) Hope it helps! I'll be happy to assist implementing if interested

Had this happen as well. Thanks for fixing in future versions.

I have opened https://git.cloudron.io/cloudron/box/issues/622

Fixed it for next release.

@girish Thankyou, will give it a go.

I can confirm that this is finally fixed now

Sogo login issues Some users have reported issues with logging into SOGo even when using the Cloudron email after the update. This is most likely because you are using an older version of SOGo. The old SOGo app was deprecated ~6 months ago as part of the 2.3 release and is not supported. Please move to the new SOGo immediately. Install the latest version of the SOGo app (from the appstore) in another location/subdomain. You should see your email when logging in with email now. If you use calendar/contacts in old SOGo, you can migrate it to the new SOGo using the guide at https://cloudron.io/blog/2018-12-05-carddav-caldav-migration.html If everything is satisfactory, you can just uninstall the old SOGo.

This was a bug in our UI code. This is fixed in 3.5

Hi @girish. Yes, I confirm that everything's green. It works after a permission change on the /home/yellowtent/boxdata/mail/dkim/mydomain.com (600 to 644) With this change, I don't have no more the DKIM error. Now, I'm trying to setup calendar with Lightning. Everything's fine but the invitations sent by Lightning; the organizer mail value is always (null) Here is the Vcalendar event : ORGANIZER;RSVP=TRUE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:(null) I can't find any clue in the logs

@nebulon ok thanks for the reply. I didn't think so but wanted to check. Would be cool if somehow the aliases you added in cloudron admin area show up as a from address automatically in sogo. Thanks again.

thanks @girish and @msbt for chiming in here. I cant see rainloop settings that support a single inbox over multi domains (but i do see how you can setup two or more accounts and simply switch between accounts) the feature in G SUITE i am aiming to reproduce here, is to have one inbox, that multiple domains are associated with, so emails to any of the domains end up in the single inbox, and upon reply, i can choose which email to reply with. In G Suite you add domains to the domain list, then under the user you can setup an email alias that span across any domain in your domain list. this is why i originly figured this was a feature that maybe cloudron would offer, but i see your point that maybe this is app level feature (just not seeing that feature in either rainloop or sogo, will try nextcloud now)

@nebulon ok thanks for the info, appreciate it.

A bit of thread necro, but I had the same problem. It appears that NodeBB is correctly configured, BUT in the Cloudron portal, by default, the "custom mailbox name" flag in the advanced app configuration settings is set to off. Thus, the email credentials correctly entered into NodeBB led to an account that, by default, was deactivated in Cloudron's mail server. For others who stumble here: From your Cloudron control panel, click the Configure tool (the pencil overlay over the app icon). In the Advanced tab of the pop-up, ensure that Custom Mailbox Name is checked, and that the name matches the name as configured in NodeBB's email control panel. By default, it's nodebb.app@. Problem solved, although whether it immediately resolved or whether it fixed when I rebooted Cloudron to install security updates about three seconds later, well ....

Just to conclude this thread. Mostly restarting the mail container will bring back the email server. As mentioned by @alexy this is done via docker restart mail

Is there any more information on this? For me all my clients I use, have the option to display folders as threaded or not, they also have then different sorting means depending on threaded or not.