SOLVED Daily notification of "Email is not configured properly", but it is...

[iamthefij]

So I recently upgraded my Cloudron to the newest version that includes notifications. Now I get this notification once a day.

When I check my email status, it's all green checkboxes (yay!), but I still get the notification.

I checked my box logs and I found:

2019-02-25T10:30:05.219Z box:mail Ignored error - relay: Error: Timeout
    at Socket.<anonymous> (/home/yellowtent/box/src/mail.js:150:18)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:410:8)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)
2019-02-25T10:30:06.347Z box:mail checkRblStatus: myhost.com (ip: 123.456.789.101) servers: []
2019-02-25T10:30:06.348Z box:cloudron checkMailStatus: myhost.com failed status checks
2019-02-25T10:30:06.352Z box:notifications upsert:  uid-9261ef5c-e91a-4d31-9575-4fb5fd7cfa08 Email is not configured properly /#/email

Looks like there is some kind of bug in the checker logic.

[girish]

@iamthefij Are you on 3.5.2? Do you use a mail relay and is incoming email enabled for the domain that is raising this error? Thanks.

[gml]

I'm having the same issue. I think at least since 3.5.1.

In my eyes all DNS checks out of the PTR are broken. When I check it manually with dig everything looks fine.

I'm using manual DNS entries and never changed anything there (but suddenly the checks went to red).

[iamthefij]

@girish 3.5.2. No mail relay. Incoming email is enabled and I'm receiving it.

[iamthefij]

@girish is the check that adds notifications different than the one used on the status page?

[girish]

@iamthefij Yes, the check that adds the notification is different from the one in the status page. For 3.5.3 (hopefully out tomorrow), I have fixed this status check. I will keep this thread open so that we can confirm that it fixes it.

[iamthefij]

Ok. Yea. I dug through the code just now and figured out where it was happening and found the log line for the failure.

2019-03-06T11:30:05.242Z box:mail Ignored error - relay: Error: Timeout
    at Socket.<anonymous> (/home/yellowtent/box/src/mail.js:150:18)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:410:8)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

[girish]

This post is deleted!

[girish]

@iamthefij When using the built-in smtp server, we do an "outbound" check to see if we can reliably connect to other servers. https://git.cloudron.io/cloudron/box/blob/master/src/mail.js#L123. It looks like maybe this is failing sometimes on your server. Is your server on ec2 by any chance?

[iamthefij]

Nope. I'm on Scaleway.

[fbartels]

Hi,

to add to this I am also experiencing these notifications. When going to the mail tab afterwards all check report back successfully. Not sending via mail relay, hosted on Netcup, v3.5.2. Error in box.log is the same as above.

[msbt]

After the update to 3.5.4 the notifications are back every few minutes. I have a few domains which are only used for forwarders (like example-domain.com to exampledomain.com), do I even have to set up email for those now?

I'm using an external smtp server now to get rid of those messages, but it would be nice to have a "No-op" option for emails as well, that just ignores the settings and does not check if outbound is working because the domain is not using email at all.

[girish]

Currently, Cloudron assumes you want to host apps on domains and thus will want to send mail. Probably not the best assumption but that's how we initially wrote it.

The code assumes that you will send emails from the domains you added. Basically, it automatically opts you in. I like the idea of having a flag to say "Allow Cloudron to send emails from this domain". Disabling this will basically stop those checks. I prefer this over disabling the check itself.

[girish]

I have opened https://git.cloudron.io/cloudron/box/issues/622