Cloudron email: feature improvements/ideas

[jimcavoli]

I recently stumbled across the MIT-licensed SPFToolbox project and it got me thinking a lot more about more comprehensive mail server features and management tools that would be good to have in Cloudron. SPFToolbox has some nice functionality for running checks for all sorts of things, but its blacklist checker is what started to get my mind running about that feature and potentially others that would be awesome additions to the Cloudron email system to help administrators manage deliverability and so on.

This probably starts to creep into a bigger re-vamp of the email management area of the product, but IMO since mail servers objectively suck to maintain, the ease of use of the Cloudron mail system is a huge selling point. While it's probably not realistic to target everything that services like MXToolbox do, but there could be some more built-in and automated to make life even easier.

Some thoughts out of the gates:

• Blacklist monitoring
• Rspamd - Haraka is ready (https://github.com/haraka/haraka-plugin-rspamd) - with some of its handy modules:
  • Possibly include web ui to shortcut the configuration management; definitely an "advanced" option though
  • Antivirus - https://rspamd.com/doc/modules/antivirus.html
  • Phishing - https://rspamd.com/doc/modules/phishing.html
  • Greylisting - https://rspamd.com/doc/modules/greylisting.html
  • Metric Exporter - https://rspamd.com/doc/modules/metric_exporter.html
    • would let rspamd feed metrics into graphite for graphing in the box ui
  • I'd favor probably pushing some of what are currently haraka plugins' responsibilities around the SPF/DKIM/DMARC space down to rspamd as well given its much higher configurability/visibility if well-implemented
• Perhaps getting into automatic cryptographic signing/encryption with something like CipherMail in the mix - definitely needs some more thought
  • This might be best done by rethinking the way haraka fits in the MTA chain - maybe making other MTA-interfaced apps available via the app store like this one would be a good thing, then in the mail server admin, you could choose which one(s) of those installed are inserted for each domain?

I'm just sort of thinking out loud here, and would like to see what others think about those ideas or any other ideas about the mail server here.

[girish]

Thanks for the ideas!

• Blacklist monitoring - would be great if we can find some service/API endpoint we can call to check the domain/IP against. We can integrate this into the Status tab.
• Do you get a lot of spam through in the inbox? If so, a first step would be to understand why SA doesn't work before/if we switch to rspamd. So far the main complaint on support was visibility into the delivery/activity of mail server and this is why we added the event log in 5.0.
• Security: on the chat, one user brought up https://www.hardenize.com/blog/mta-sts . Have to look into this more.

[jimcavoli]

The code from SPFToolbox just kicks back JSON - maybe the author would be okay with putting the hosted version up to service those API requests? Alternately, it could be deployed centrally for support or as an internal tool for checking DNS stuff generally within box.

I don't think that SpamAssassin doesn't do a decent job already anyway for most of the accounts I manage; it just has to be trained. I think the value of rspamd is much more on its transparency and ease of management over a wider breadth of features. I postulate that giving it more delegated responsibility from haraka would pass those benefits on to the mail server solution overall.

MTA-STS would be a great add as well! Hadn't even thought of that

[d19dotca]

@girish I may be off-topic but I’d like to add that that the current issue with spam control is there’s almost no configuration available, meaning I can’t do any of the following (or if I am able to then I’m not currently aware of how to do them currently):

1. Set the aggressiveness of the filtering
2. Make my own blacklist of domains or email addresses
3. Make my own whitelist of domains or email addresses
4. Enable or disable different rule sets such as changing how many “points” a certain rule will add to the spam results for example

On top of that, might just be me, but I find the learning takes longer than desired too. It seems like it needs a lot of the same type of message before it starts to filter that type of message out of my inbox.

Don’t get me wrong, it works decently well out of box, I think it could just be greatly improved (from various different angles) as well, with the list above being a nice addition to giving more control over spam handling in the Cloudron server.

For what it’s worth, rspamd also seems to offer graphs so an admin can quickly see at a glance how much is identified as spam, how much is greylisted (does greylisting even occur in Cloudron right now?), and how much is non-spam. While this isn’t required info it can be nice to have some statistics so people can get a better idea if it’s improving or not, especially if they’re wanting to make changes and run some comparisons, etc.

[necrevistonnezr]

@girish said in Cloudron email: feature improvements/ideas:

• Security: on the chat, one user brought up https://www.hardenize.com/blog/mta-sts . Have to look into this more.

See this article by Tutanota as a starting point: https://tutanota.com/blog/posts/tutanota-letsencryt-launch-mta-sts-tls/

[Mallewax]

What about full text search for Cloudron e-mail boxes? That is probably the only "one real feature" I am missing.
Thanks to Cloudron I have successfully "de-googled". It is just that I came to appreciate FTS while I was still on google mail.
Is this in the cards?

[jdaviescoates]

@alotz said in Cloudron email: feature improvements/ideas:

Is this in the cards?

Yes, as you've spotted it was mentioned in what's coming in 4.5 announcement thread.

[d19dotca]

@Mallewax Do you mind providing an example or explaining what FTS is exactly? I ask because I always thought this feature was more client-oriented. For example, I can do complete text searches via the Apple Mail client and find any message I’m looking for. So what does adding FTS on the Cloudron side do in this case? I’ve never had a problem finding a message. Maybe I’m thinking of something totally different though? Just want to make sure I’m on the same page on this full text search thing.

[mehdi]

@d19dotca I guess it's not the same thing when you are using a webmail client instead of a desktop app

[d19dotca]

@mehdi But even in Roundcube for example, I’ve never struggled to find a message I search for. That’s why I’m confused on what the advantage to FTS really is. Maybe I’ve just had good luck? lol. I mean if it improves search on webmail providers than cool, but I just wonder if it really would because the webmail apps are also just clients and I always thought this was a client-side feature, not server-side.

[NCKNE]

The IMAP protocol (also used by webmail) can offer a server side search for the clients to offload the search for the client to the server. Using full blown clients like Apple Mail do not really need this as Spotlight on Mac OS already indexes all mails, but especially for webmail/groupware clients this is very useful.

[d19dotca]

@NCKNE Sure, but as I mentioned earlier, I have never personally had an issue with the webmail clients either. I've always been able to find the message/email I was looking for (I was using Roundcube specifically more than Rainloop if that matters).

So I guess I have to ask... what problem are we actually trying to solve here with FTS? I'm just not convinced there's a problem to begin with. I worry that we're asking for something just because we think it should be available but without really grasping the full picture. Is there an example I could try with in webmail where I cannot find a message based on a particular set of data? Maybe I just need to experience this myself before I recognize the benefit of FTS.

[NCKNE]

@d19dotca For small mailboxes, the client side webmail search might be good enough. Implementing a server side search can speed up the fulltext (eg. text within the mail body) search by a lot though. I am personally more keen on the implementation itself (solr or elastic search) as this core service could be offered to other apps such as Nextcloud for a fulltext search in documents as well.

[Mallewax]

@NCKNE Thank you, this is exactly my point, too. Sorry for not having been clearer. It is mostly a performance issue. IMAP Server-side search works sequential, without an Index.
For smaller mailboxes not so much an issue, but for larger ones very clearly noticeable.

Here some more background:
https://doc.dovecot.org/configuration_manual/fts/

Also, before I switched to Cloudron for my e-mail needs I got my feet wet and installed an e-mail server from scratch by following

https://workaround.org/ispmail/buster/

This was mostly for educating myself. I then migrated my ~ 7 GB Gmail over to this server, and this is when I realized that there is a huge perforamnce difference in search speed. The set up at "workaround" is just a "vanilla" Dovecot IMAP server.

I then managed to install Apache/Solr on this setup and it is then when I realized how much IMAP search improves.
From minutes to seconds...

Hope this helps to shed more light on my desire...:-)

Cloudron rocks and I am super happy with what I have now....even without FTS (yet)...

[d19dotca]

@Mallewax what would you consider a small mailbox? Mine is over 6 GB right now and again - no noticeable issue at all. Everything I can find very quickly in both Apple Mail and webmail on Cloudron. I just can’t see the benefit yet, still.

[Mallewax]

@d19dotca That's quite interesting. 6 GB is certainly a big mailbox. And that you find everything fast on Apple Mail is not surprising, as Spotlight Index works on your mailbox. I am just surprised that the same seems to work for you on Cloudron (Roundcube or Rainloop, I suppose).
At any rate, I can only refer to the Dovecot reference again, where the developers themselves explain how indexing solutions improve the search speed.

[marcusquinn]

Great thread!

I kinda like these guys attitude to Spam filtering: https://posteo.de/en/site/faq

(they run on Roundcube for webmail too, so decent endorsement)

"Is there a spam folder?
No, with Posteo there is no spam folder. This was a conscious decision we made. It has advantages for our users. Messages that are not spam can end up in spam folders, where they remain unattended to. The sender thinks that the emails were delivered and read, which often leads to problems.
With Posteo, there are only delivered or rejected emails.
Our spam filter conducts checks against various criteria in the process of receiving an email. If an email is classified as spam, it will not even arrive. The sending server can not deliver the email and informs the sender of this.
The sender can either ignore the reason for classification as spam or try to contact you via a different method. In any case, they receive a notification to say that the email could not be delivered. This process ensures that no email goes missing."

[d19dotca]

@marcusquinn If that is the method we want to go with, I'd suggest that before it's added as a feature that admins have the ability to fully control/dictate what we want to see rejected at the SMTP level. In general, it's considered "bad practice" to block at the SMTP level although it's also a common practice to still use at least one DNBSL like SpamHaus or SORBS, etc.

@girish, any way we can possibly get better spam control added to 6.0 or 6.1? It'd be great to see the spam controls open up and be more customizable to admins of Cloudron servers. I know this particular thread was started just a few months ago but myself and others have requested improvements back in 2019 too: here & here and I'm sure there's a few I missed too.

[marcusquinn]

@d19dotca Yup, anything potentially destructive should always be opt-in. There will always be preferences but having the options helps please more of the people more of the time eh

[girish]

This idea comes from @MooCloud_Matt but he did suggest that for advanced users we should allow the spam filtering to be "outsourced" to a service. For example, apparently Proxmox Mail Gateway can do a lot of the greylisting etc. Would you guys be more interested in building this into Cloudron or integrating with an external service? An angle here is that this external service can learn across all your clients and not just single Cloudron instance like it is right now. To be clear, we won't be providing or building this external service. We will just be integrating with it (like different DNS providers, storage providers, this is just a Spam filtering provider)

[d19dotca]

@girish I'm not sure if I'd be able to take advantage of this, though it depends on how it works I guess. If it means my mail leaves Canada for review by a third-party service, then I don't think I can legally do that as a few of my clients are in the healthcare industry and require to be kept as-much-as-possible on Canadian servers. I'm certainly not against it, but it'd be great to just have more control opened up in the existing setup local to Cloudron.

[MooCloud_Matt]

@d19dotca we are working as moocloud on 2 possible solution:

• Complete antispam proxy in cloud

• A boost to the internal SpamAssasin in cloudron.

the second case will use signature db to provide a more effective SA score, for both virus, spam and ham.

But the first solution will offer the best resolute, and less ham especially, per user whitelist/blacklist and premium signature for spam, and virus scanning.

[MooCloud_Matt]

I try to summarize the feasible and effective antispam scenario/stack:

• Rspamd
  • It does practically the same job as spamassasin, he needs less training then SA.
  • spamassassin seems more effective than rspamd if configured correctly, thanks to the use of signature exchange nextwork razor, pyzor, ecc ecc.
  • an antivirus(clamav), is impractical for cloudron, because it would require at least 1.5 / 2 GB of ram to have the entire signature database to be fast enough to filter emails, and as far as we are concerned 90% of our customers do not have such resources on the vServer.
• SPF/DKIM/DMARC
  almost all spam is now signed with these protocols, therefore further control by the antispam is normally useless.
  what cloudron does from this point of view is already excellent, haraka is much faster than SA or Rspamd, it would be a waste of resources in most cases to make the antispam and not the MTA do this job.
• DNBSL
  if well configured these work very very well, but many of these do not allow to be used by anonymous servers and many others are paid, for this reason we suggest the use of a proxy or for all emails or at least for parts of the antispam-system such as DNBSL, signature.

[d19dotca]

I'm a little worried we may be getting off track with the request for more mail server control versus what's being proposed, but maybe I've just misunderstood the more recent proposals (in which case I apologize for any confusion).

I'm definitely not against a third-party service to integrate with if others can take advantage of it (I don't think I could unfortunately but that's fine) and it improves things. But what's being requested by active users are things that should be ideally all local to Cloudron without the need for a third-party service.

What's being asked for by users isn't really any different than what other "all in one" mailbox platforms/solutions have been offering for many years (in some cases decades)... such as the following:

• Mailcow
• Mailu
• hardware/mailserver
• iRedMail
  and others

Admins of a mail server should:

• Have insight into how many messages are being sent at any given time (separated into blocks of time such as hourly, daily, weekly, monthly, etc.), how many of those are delivered vs rejected, etc to be able to see their delivery rate and adjust other settings as needed.
• Be able to set their own rate limits for how much mail can go out in a given period of time, ideally by domain and global.
• Configure what folders spamassassin uses for learning from.
• Be able to control the spamassassin rules and their weights, and whether that applies to all users or just certain users, the ability to disable rules, etc.
• Be able to combat spam through greylisting capabilities.
• Edit blacklists/whitelists (or denylists/allowlists) through the GUI rather than command-line.
• Control which mail folder names are used during creation of a new mailbox.
• Look at the mail queue status, clear out the queue if needed, re-send, etc.
• and plenty more

Now I know the last few comments have been more specific to spam control, and a few of the ones above are also on spam control and really should all be done local to Cloudron (such as exposing Spamassassin configurations, greylisting capabilities, editing the denylists and allowlists, etc.). I just hope that with the recent proposals to use some sort of proxy to offload to a third-party spam service, that we're not offloading these user requests and chalking it up as done. I hope that we're still going to be doing spam filtering local to Cloudron, and that more controls are coming local to Cloudron too. This is most important for those who aren't even able to use a third-party service that views the messages if the service provider doesn't operate in the country needed for the data processing to be done in (such as healthcare providers who generally need to host their data in the country they operate in and remove as many services from the equation that don't operate in the same country).

My two cents. And again, my full apologies if I've misconstrued the direction this is going in, I just wanted to make it clear that I think most of us (if not all of us) still would like these improvements we've requested to be made local to the Cloudron app rather than offloading to a third-party service. With that said, a third-party service would be a nice addition - but it should be just that, an addition rather than a replacement.

[MooCloud_Matt]

@d19dotca Your questions/notes are all very interesting and relevant; Our problem lies in the optimization and management of resources.

Our problem lies in the optimization and management of resources.
To work properly if you control from Mailcow to iredmail they ask for 2GB to 4GB of RAM (I am not considering using more effective ClamAV databases, no OCR filters or anything else.).
This is something that almost none of our customers (moocloud customer not cloudron) can have, moreover there is a reason for the increasing use of proxy or MTAs by professional antispams instead of spamassasin plugins, spam must be fight together, collaboratively and this is not possible if you install an antispam on each server.

What MooCloud has proposed to cloudron (this is one of our 2 proposal) is to offer integration with a popular antispam proxy, we are talking about proxmox gateway that you can all download and install and use to manage all your incoming mail.
What MooCloud will do is offer this package/proxy with additional filters, various optimizations to improve effectiveness.
Proxmox come with many interesting functions already available as "Object-Oriented Rule System":

Rules:
ACTIONS - object: Defines what should happen with the email.
WHO - object: Who is the sender or receiver of the e-mail?
WHAT - object: What is in the e-mail?
WHEN - object: When is the e-mail received by Proxmox Mail Gateway?

Or the second proposal is to offer a set of tools that collaborates with the cloudron server, spamassasin and haraka to improve the score.
In this case we will ensure that only the email signatures are sent to our servers and not other information (This is 100% compatible with any privacy policy of any state.).
Obviously in this case if we could offer this service; Cloudron will allow others to enter the competition and in some time you will have the opportunity to take advantage of the choice of multiple providers.
This second setup, however remains that it is not as effective as the first solution and will take a long time to develop.
because it will take time to integrate Box (cloudron backend) with haraka, spamassasin, clamav demon, pyzor, geoip repository, sieve, etc. etc.
Remember that all the software you mentioned earlier took years to become usable and complete as they are now.

What I can tell you is that: I understand your concern about not being able to use certain services, but unfortunately antispam is something really complex to manage locally (in fact microsoft's exchnge no longer does antispam, and is the first mail server used my enterprise) and I am sure that any solution choosed by cloudron (among ours or others that will be made); if this needs to have external servers/service they will be distributed globally.

[d19dotca]

@MooCloud_Matt "optimization" and "management of resources" are important factors in anything for sure, but most of what is being asked for is just exposing already functioning components, so naturally those shouldn't really take any more resources. It isn't so much adding entirely new features that we're asking for (although perhaps a couple), just exposing what's already there (for most of the suggestions).

Most Cloudron users are likely running on at least a 4 GB VPS, probably 8 GB or even 16 GB is the sweet spot depending on how many apps they're running.

As an example on memory... running the Mastodon app is a 1 GB requirement for example, and I'm betting that more users use Cloudron for email than running the Mastodon app, so presumably there'd be a lot of people happy to dedicate 1 GB of memory to additional features to managing their emails better.

Again though, I don't even think additional resources are even necessary here for most of the requests from Cloudron users, unless adding an AV scanner is important (personally I don't think AV is needed but it would be a nice-to-have as a feature we can enable or disable).

I think what most of us are asking for are simply exposing existing functionality through the GUI, and a little bit of new functionality perhaps such as queue management and rate limiting. That's about it. As a result, I'm confused by the recent comments for some off-box spam solution. Again, not against that as an additional feature - more options are a good thing, but it should not be the solution as it doesn't really address what most of us have been asking for, IMO.

My fear is we're looking to off-box spam control entirely and I don't think many of us are wanting that to happen, at least not as the only solution to improving spam control.

[girish]

Don't mean to side track but there should not be problems exposing more controls (like bl/wl, mail queue etc). From technical point of view, we don't want to expose SA specific configuration too much because we want to keep the option for rspamd open. So a first pass is just exposing things that we already can do easily.

edit: missed an important word @d19dotca

[d19dotca]

@girish Definitely in agreement with that. I assume you mean "should not be" rather than "should be" though. haha But yes, exposing what's already working on the lower levels is mostly what people are asking for and that's what I'd like to see happen and I believe most users would say the same thing.

And that's understandable to be hesitant for now on opening up the SA config if you're pondering moving to rspamd down the road, I think most of us would be okay waiting a bit longer for that decision to be made and then investing the time on the solution identified.

[MooCloud_Matt]

@d19dotca
I'm not saying that some functions like blacklist and whitelist should not be included in cloudron, but these will not improve antispam effectiveness, they will make it more functional.

But to make it more effective you need some things, and one of them is Clamav, because many spam repositories are included in the clamav or other antivirus signature-repo.
For this there are repositories for ClamAV updated every hour with the largest and most common spam attacks at the time on the web.

And this becomes complex especially when you need to use networks like pyzor, razor or DCC.
This means that a server loses at least 2 GB and becomes complex to manage, because in order to function properly they need to be used on a network.

What I am convinced: is that @girish can make cloudron more functional, but to improve effectiveness you need to find a different solution.
This is not my belief, if you look at all the control panels they always offer external solutions or special addons for spam, because protecting from spam is a high cost, in term of time, money, resources.
We modify the words and phrases that spamassasin must observe more carefully every week, during the period of the covid pandemic almost every day.

[d19dotca]

@MooCloud_Matt I think I may see now where some of the confusion is coming from now. What you're talking about is effectively an entirely new functionality (integrating Cloudron with third-party spam services), and what most of the rest of us are talking about in this thread is simply asking for Cloudron to expose existing functionality to Cloudron admins so we can improve how our mail servers act for our users.

The title of this thread is very generic but I think it might be helpful if you started a dedicated thread specific to requesting the addition of third-party spam services and having Cloudron integrate with those APIs, because I think that's a very large topic all on it's own that may require a lot of discussion. Just my two cents anyways.

I'm certainly in favour of your suggestion for a third-party integration for spam filtering - the more options we have the better (as long as it's still maintainable for the Cloudron team) - although I respectively disagree with the implication that a third-party service is the only solution to improving spam filtering "effectiveness" in Cloudron. Plenty of large corporations (receiving far more mail than any of us Cloudron users likely are) deal with spam in-house, though admittedly they will also have far more resources to throw at it.

There is still a lot more we can do within the confines of what Cloudron already does to improve spam filtering effectiveness, we just need those functions exposed to us to better modify them to our liking.

[mehdi]

@girish said in Cloudron email: feature improvements/ideas:

we don't want to expose SA specific configuration too much because we want to keep the option for rspamd open

I completely understand your approach, but I do not think exposing the configuration more would prevent you from changing the spam engine later, as long as the documentation makes it clear that customizing said configuration may stop working later and that you only make the change in a major version.

[girish]

@mehdi Yeah, just trying to reduce some work for ourselves. I think we just need to take some time to evaluate rspamd

Does anyone here used rspamd in prod for long periods and willing to share their experience?

[d19dotca]

@girish I used rspamd a year or two ago as part of hardware/mailserver project on GitHub, it was great. With that said, I had not specifically installed rspamd since it came with that project (own container), but it pretty much just worked well out of the box, didn't have to do too much tinkering with it. It gave great reports and such too which I really liked, seeing how much of my email was deliverable, how much was flagged as spam (incoming) vs legitimate, greylisted, etc.

[jimcavoli]

Love the conversation this has kicked off, and I think there's a few good things to consider here:

• The main thing I was originally aiming at first was better visibility into the mail subsystem and second to that more control over those various components
• Expanding the capability of the mail system to include additional processing by farming out additional processing to external servers like CipherMail, Proxmox, etc. could be done easily for even sparsely-resourced servers. However, optionally enabling certain processing like Antivirus on the same machine is still likely a good idea.

A lot of us are also running fairly beefy servers for large production setups and it seems disingenuous to rule out completely more resource-intensive operations from the core packaging just because some machines at the lower end couldn't support them. Making them optionally available, even subject to certain resource constraints and so on, is exactly what I'm hoping we can get to - a lot more control over the mail system so that administrators can choose how much in terms of resources to invest in that system. A combination of more inspectable, optional services available on the core offering as well as allowing external smtp-based components to slot into the workflow sounds like the best of all worlds.

[paenzy]

A very nice feature for cloudron mail is a per user/mail signature.
With this feature you can managing all disclaimers central in cloudron and don't need to change each disclaimer in the client. All mails would have the same corporate disclaimer - no matter if the mail sends from outlook/thunderbird or mobil app.

In my opinion, a central managing company mail disclaimer for SMTP server is definitly a unique selling point.
(many companies dont't use exchange server)

What do you think?

[girish]

@paenzy currently, disclaimer can be set a domain level - https://docs.cloudron.io/email/#signature . BTW, this feature request post is very broad, feel free to open a specific request as a separate post. It's easier to track and vote.

[jimcavoli]

@girish To that end, perhaps this one is better locked at this point