Cloudron Forum

@aartjansen don't you see a retry button in the UI?

Hello @milohiss @milohiss said: Are maintenance emails sent only when a notice is first created? Can its dashboard timestamp change without another email being sent? Yes to both, and that is exactly what you are seeing. Email fires when the notification is first created, or when an already-acknowledged notice is re-raised. An unacknowledged notice that keeps re-pinning gets its creationTime bumped every run and the dashboard renders that field and sorts by it, so it looks brand-new at the top of the bell while no mail is generated. The August email was the original send, nothing has been "missed" since, by design. @milohiss said: What read-only diagnostic can distinguish expected suppression of repeat notifications from a failure to generate or send the email? In the box.log you could find lines like: mailer: Email "..." sent to ... for a successful send Error sending Email ... for a real failure notifications: add: <type> <title> for a notification being added logged only on insert not on update @milohiss said: All available email notification categories are now enabled. Does this cover every new bell notification? If not, which are dashboard-only? They cover every notification that can produce an email. But several bell notices have no mailer and are dashboard-only and these are: cloudronInstalled, cloudronUpdated, ubuntuUpdate (for EOL warnings like Ubuntu 20), mailStatus (Email configuration error), domainConfigCheckFailed, appUpdateCheckFailed Maybe this is something we could improve. @milohiss said: Is there a supported way to receive email reminders for unresolved urgent notices? Currently, there is no reminder/re-nag timer. The one supported lever is the acknowledge transition: dismiss the notice in the bell, and the next check (≤24h for reboot, ≤4h for updates) re-raises it and sends a fresh email.

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

@sebastienserre said in Email questions: When I received the email, the "from" header is "Matomo" which is another apps I'm running on the Cloudron. This is coming from somewhere in Dolibarr. The from name is not part of the SMTP protocol , it's inside the email body. Can you go over the SMTP settings inside Dolibarr again?

Right, the haraka log can be ignored. I think the IP and cert name don't match and thus the warning. It's not a problem since such mails don't leave the server.