@roru2k20 I see. Just to double check, the above DNS records are for the thirdlevel is it? If not, they should be added as "thirdlevel" and not just "@" (for the SPF record at the bottom)

@d19dotca thank you, I appreciate your quick response and correcting on the wrong topic!

I did the search indeed, but I guess it was a wrong search query 😃

@artd2019 Currently Cloudron does not offer (a documented) "whitelist" / "allow list" function, so there is no way to guarantee deliverability of an incoming email. There is a feature request for it already that I'd encourage you to upvote. Version 6.3 coming in the not too distant future is supposed to deliver on many of the email improvements users have been clamouring for (including myself).

One thing you can do if you're not already is making sure to remove those emails from the Junk / Spam folder in order for SpamAssassin to unlearn the message as spam. Eventually after a sufficient number of them, it'll learn that those emails are not spam and will decrease the BAYES probability of it being spam.

On a related topic, you may want to consider enhancing your SpamAssassin rules list from the defaults, specifically in your case the BAYES_## rules perhaps as I have offered previously in this forum.

@girish Cool, thank you kindly. It's just for incoming mail to those addresses for the time being, but I may add auto-responders from them as well at some point.

For interest, I'm setting up all sorts of automations in EspoCRM, so tasks@domain.com will create a Task record and auto-reply to confirm it's been created. Doing similar for other data objects to.

Thing is some apps store the email (just like they store username) in the database. This means that when you change the email in Cloudron, it doesn't change in the app (depends on the app). So, just to keep things easier across apps, we decided to keep login username based as much as possible (since in Cloudron, you cannot change the username, we don't have a problem).

@girish I think that would be a good change.

I also think I should have gone through the Troubleshooting document sooner 😸 :

https://docs.cloudron.io/troubleshooting/

Thanks!

@subtlecourage said in Outbound SMTP not working on my External Relay:

It says it should be coming from noreplay@domain.com, but instead it is coming from imanalias@domain.com

Can you clarify what you mean by "it says"? Is there some error/warning somewhere? Also, I assume that you have put a custom domain in fastmail and also fastmail is able to relay mail as any email address i.e <anything>@domain.com ?

@d19dotca Sadly, they do match. I'm guessing it's something with my current setup that's acting funny. I'll ignore it for now since I plan on migrating either to the new Contabo server that I got or upgrading my current one at DO to Ubuntu 20.04. I just thought it was a wrong setting on my part.

Thank you for looking into this and for sharing the custom spam rules! I know you've put a lot of time into that 👍

2443c4d7-ec13-4149-add3-28e1e7ad48ed-image.png

@d19dotca Perhaps even a per-app option, as in "Check for spam sent from this app."

@girish said in Email into apps - DNS/MX/CNAME/TXT:

You have to setup the CNAME/TXT for the root domain and not for my.example.com. You don't have to set it up for each app individually

Thank you. That was my main issue.

@jdaviescoates said in Role required to enable mailbox creation:

@nebulon said in Role required to enable mailbox creation:

it may actually make a lot of sense to allow the usermanager role to also manage mail related things. Not sure yet, feedback welcome.

Yes, I think User Managers should be able to create email accounts too, given that in many cases a new user will also need a mailbox.

And I can only agree with that guys.

Thanks, I have put a note in https://docs.cloudron.io/email/#autoconfigxml

@d19dotca since we had some recent timeout issue with the services view (and mail being a service here) it could be that also here the mail container or the server overall is busy during that time and thus the search queries timeout. If you see this happening again, a look into the system/box logs as well as mail service logs should reveal this then.

Yes, this needs to be a setting! Even if manual via console.

I just realized part of this is a duplicate of one that @marcusquinn filed earlier for Add a setting for sendmail limits per mailbox per day

For reference, Haraka has a greylisting function built in: http://haraka.github.io/plugins/greylist/ - and it works with the DNSWL / whitelist which we should enable too. That way if an IP is on the DNSWL, it automatically skips any greylisting attributes.

@girish said in Change to the DKIM record hostname in recent version, caused by new feature or from using NO-IP domain provider?:

If it was random, I was afraid there is still a possibility that they can conflict across servers

Great point - that makes sense. Thanks Girish.

Side note: I think it'd still be great for the OCD in some of us to be able to regenerate the DKIM record on demand so it not only follows the new hostname pattern in Cloudron but also generates a new key if desired too.

@nebulon thank you! worked perfectly fine and is very helpful 😄

@mdreira said in Lightmeter - Mail server delivery monitoring:

What mail server does Cloudron use? Exim?

This is what Cloudron uses for smpt: https://haraka.github.io/

@nebulon Will do, thanks!

You can set flags on the email with sieve filters. I think this is only available in roundcube UI though.

bf4f52b4-5648-41a9-aca2-f799daadb640-image.png

Then, in thunderbird, you can highlight them accordingly - https://support.mozilla.org/en-US/kb/message-tags

@privsec said in Let’s encrypt certificates expiring?:

Like can there be a memory within cloudron of all subdomains used and when it comes time to renew, just renew it on all of those subdomains?

That's the current behavior. It only renews domains that are in use in Cloudron. AFAIK, there is no way to tell Let's Encrypt to "forget a subdomain" that we had gotten a certificate before. This is the reason why you get the reminder emails from Let's Encrypt about old domains.

@marcusquinn It's a more general tool as an attempt to fix and replace the issues with Email in general. It does that well.

It just needs adoption.

https://hacker10.com/computer-security/send-email-with-tor-i2p-and-gpg-using-confidant-mail/

https://privacytools.io has other options too

@paenzy I read somewhere that adding terms and disclaimers to emails made then "contractual", so in some cases and places it is better not to have them.

I'm always interested in what's supposed to be law and what becomes hearsay law because lots of people do it and tell each other it should be done.

I don't have experience either way but tend not to use email signatures from both habit and to be personable.

@masonbee Re: Email authentication failure

Solved. Duh, I changed my password and never realised the emails weren't on independent passwords.

I really like the blackllist checking being built-in. Frankly, I'd also be a fan of getting notifications about it. I suppose UX-wise, perhaps this is the appropriate sort of thing to trigger a yellow status on email.

The root cause for this was the Cloudron server had the hostname as "box.domain.com" (same as the relay). Debian/Ubuntu has a quirk that it will put the hostname in /etc/hosts to resolve as 127.0.1.1. This meant that when we try to set it as relay, it resolves to 127.0.1.1 instead of the actual IP.

To add to the confusion, I suggested using the host command which does not use /etc/hosts (i.e the nsswitch mechanisms) and uses only the DNS. If I had suggested using ping then we would have narrowed down the issue more quickly...

Anyway, the fix is simply to hostnamectl set-hostname somethingelse.domain.com and also edit /etc/hosts (for some reason, hostnamectl doesn't change hosts file even after reboot, 🤷 ).

@imc67 currently, there is no manual way to do it since it will get overwritten after restart.

@drpaneas said in gmail blocks my server?:

@jdaviescoates I have cloudron installed at home.

Ah, right.