Cloudron Forum

Thanks, I have fixed the regression.

@msbt previously, forwarding feature did not use sieve rules. It was implemented in Haraka, so this setting was not needed.

The issue here was a tika crash and not solr. Tika processes attachments like PDF/ODT etc. It's unclear why tika itself crashed. The logs are inside the mail container at /run/tika/tika.log if you want to dig into this further. But generally, a retry will pick up things from where it left off the last time around.

@james Thanks ~!

@LoudLemur said: @necrevistonnezr has a valid point, too. What else can we do, though? "Understand it better?" This problem meant people were not receiving emails. Not sending a bug report, particularly when the ai had found a fix, didn't seem public spirited. It also is a bit like self-censorship. It’s pretty simple: Read the output, work with it it, make it your own. Don‘t just forward it unfiltered. If that’s too much, leave it. In case of a bug report, if you don’t want to put in the work, what’s the point? How does the team know your report was verified by you and has merits? It would probably more helpful to leave the team your result in 3-4 sentences and provide the prompt - then they can see for themselves.

Thanks for the report @d19dotca . It's fixed for 10.0.2. The issue was that when having multiple internal forwards, sieve was adding multiple headers. The haraka code headers.get() was concatenating all the headers with '\n' and this caused a crash since I wasn't expecting haraka to concat it this way. There is a get_all() API which returns an array and I pick the latest forwarder from there.

yes, direct url is working again. That was it! Applied the one line change on all three servers here and the 60 query test goes from 20/60 to 60/60 on each of them. For reference, temperror was running at 48%, 34% and 18% of inbound mail over the last 24 hours on those three. I will report back once enough new mail has come in to see where it lands. Thanks for digging into this so quickly.

Okay, thank you!

Hello @sebastienserre Did you enable IPv6 in the Cloudron dashboard? Does the IPv6 detected in the dashboard match with the IPv6 provided by your hoster?

Thanks - I see where you are coming from, but this is not directly what I aimed for with my initial post as a cheeky attempt to get consideration for a mail archiving app officially packaged for Cloudron. nonetheless, I see both as valuable topic of discussion: Legal compliance with business email archiving, especially in transactional email scenario - as a Cloudron feature tight to cloudron email server Email archiving app, possibly providing the above functionality by delegation of the feature but also enabling the archive of other emailing solution not residing on Cloudron (e.g. gmail, outlook etc..). Selfishly, the later is what is most attracting to me due to the need of archiving emails from various email solutions / providers as well as cloudron ones.

The core issue was a quoting problem. It was mistaking "-" as an argument instead of a folder name. Fixed in https://git.cloudron.io/platform/box/-/commit/04adf5de3470a944cf811a23613bceb9ea520b38

@imc67 So were we using the same rules from @d19dotca ? For now I removed from all istances, but in future I want to keep only rules who works in local, not requiring any outbound connection.

@girish That is fantastic news, looking forward to it. thank you cloudron team!

Could you please check whether this applies to the PTR4 record as well? As I hadn’t configured it on the Cloudron – since I was using a relay – I experienced issues with incoming email delivery until I configured it. I then configured the PTR4 record and everything was solved. I know that PTR4 record is related only to outbound, but I want to figure out if there is some relationship on what happened. Thanks a lot

Small update from my side. I contacted Spamhaus through their ticket system and after communicating with them it seems everything is now resolved and the IP has been removed from the blacklist. Emails are working normally again. Sorry for the false alarm and thank you for your help and responses. I did notice that occasionally I still see the error that was present in the previous version, so I will keep

Hello @diego @diego said: However, from a system design perspective, I was wondering if it would be better to: keep the system disk small (OS + Cloudron core) attach a separate disk dedicated to mail storage Yes you can do that. I also do that with my private Hetzner server so I can scale up the CPU/RAM and have the storage seperate. @diego said: Will the Cloudron backup system still include it normally? Yes. If you move e.g.: /home/yellowtent/boxdata/mail to /mnt/sdd1 and create a symlink so /home/yellowtent/boxdata/mail => /mnt/sdd1 this still works. What you can always to is creating a small Cloudron server to test and tinker as much as you like. This way you get a better feeling for everything without risking any damage to production.

@joseph omg! thank you so much for pointing in the right direction. i did upgrade our servers on Netcup a while ago, i kept the old ones in case i needed any data, turns out, the VMs had an autostart set and were running again.... Thank you! Case solved (i hope)

Just to come back to the previously suggested solutions - Would it be a big feature request to add group name parsing into the mailing list input box? E.g. instead of (or in addition to) a list of email addresses it could take something like "group:foo" and then this would dynamically pull in the email addresses of all users in group foo as needed. Is there a way that cloudron user group info could be pulled in @roundcube (or another mail system), so that instead of setting up forwarding rules that go to a list of emails it could go to "group:foo". Is there a way that we could run a cron job (or similar) which could hackily create either of the above functionalities by generating and inserting the lists (rather than these lists being dynamically generated), with the downside that this would only ever be as up-to-date as the frequency with which the cron job runs.

Hello @pistou79 Always happy to help.

No, For spam filtering. I've moved to Postfix. I didn't like how locked down the MTA is.