Change request: Notifications in Cloudron 3.5.1

[nebulon]

We have explicitly made email status notifications sticky until resolved. We have done that, since most apps are able to send out emails and thus those mails would always end up in spam or right out get denied by the receiving email server if those things are not setup. So in your case you don't care about such emails being lost? If there are good reasons to not nag the user about those issues, we can add some "ignore" setting I guess. Maybe you can describe your use-case about this a bit further.

[msbt]

I'm getting those notification also, but I'm using an external SMTP server. So technically there is no issue, but the error messages are showing up again shortly after clearing them.

[girish]

BTW, there was a bug in 3.5.1 about incorrect notifications about mail setup. This is fixed in 3.5.2 and we have started pushing this out over the weekend. Can you tell me if the notification goes away after you updated to 3.5.2?

[msbt]

It is still there on 3.5.2, haven't restarted the machine though, but I reckon that shouldn't be necessary

[odie]

@nebulon said in Change request: Notifications in Cloudron 3.5.1:

We have explicitly made email status notifications sticky until resolved. We have done that, since most apps are able to send out emails and thus those mails would always end up in spam or right out get denied by the receiving email server if those things are not setup. So in your case you don't care about such emails being lost? If there are good reasons to not nag the user about those issues, we can add some "ignore" setting I guess. Maybe you can describe your use-case about this a bit further.

I understand why you do this. For me, these are issues I am aware of.I wouldn't use my Cloudron email server for critical issues for this exact reason. If I need a better assurance that my e-mail can be transmitted, I would do what msbt does - use an external smtp server.

Since I self host, it is not possible for me to get a PTR record (since my ISP uses dynamic IP's, they don't offer this functionality). So for me, the cloudron mail server is basically a place where I can receive email notifications from different automated tasks/service, and where I can live with the reliability issues.

For me, the preferred fix would be an ability to either block these setup warnings, or to have the functionality msbt describes, if setting an external smtp server would be considered a valid setup by the email notification system. It's not a big sacrifice for me to use an external smtp, although I would prefer not to (the allure of completely self hosting, and not leaving any traces on external services for private notifications from private automated services is a big "privacy plus" for me).

Also, I would like it if the email notification was satisfied with being "off" for domains that don't have email configured (at least if the Cloudron is setup with at least one working email domain).

Thanks for looking into this so quickly

[necrevistonnezr]

@odie said in Change request: Notifications in Cloudron 3.5.1:

Since I self host, it is not possible for me to get a PTR record (since my ISP uses dynamic IP's, they don't offer this functionality).

That's my set up as well and turning the notification off would be great.

[girish]

I see, we will remove the PTR check atleast so that it doens't trigger the notification. Would that work?

[msbt]

For me I don't know if that's the reason. In the status view everything is alright (because of the external smtp server). But I have the green check-symbol right beside "Outbound SMTP (Relay)", but still the notification pops up.

[girish]

@msbt Are you on 3.5.2? Once you mark the notification as 'read', it won't appear again.

[odie]

For me, it would work to turn off the notification for PTR, if we also could have the notification turned off for (secondary) domain names that are configured to have the email server "off".

Come to think of it. The notification probably shouldn't fire if email is "off" on a domain. At least not more than once.

[msbt]

thanks @girish, works now!