Status Checks Change Warnings

1

MiaB regularly sends status check messages, most of which are expected. For quite some time now I have been receiving messages similar to the following:

box.mydomain.co.uk -- Previously:
==================================
✓  Nameserver glue records are correct at registrar. [ns1/ns2.box.mydomain.co.uk ↦ 1.2.3.4]

box.mydomain.co.uk -- Currently:
=================================
?  Nameserver glue records (ns1.box.mydomain.co.uk and ns2.box.mydomain.co.uk) should be configured at your domain name registrar as having the IP address of this box (1.2.3.4). They currently report addresses of [timeout]/[timeout]. If you have set up External DNS, this may be OK.

box.mydomain.co.uk -- Removed
==============================
✓  The DANE TLSA record for incoming mail is correct (_25._tcp.box.mydomain.co.uk).

sub1.mydomain.co.uk -- Previously:
=====================================
✓  MTA-STS policy is present.

sub1.mydomain.co.uk -- Currently:
====================================
✖  MTA-STS policy is missing: STSFetchResult.FETCH_ERROR

sub1.mydomain.co.uk -- Previously:
=====================================
✓  autoconfig.sub1.mydomain.co.uk: Domain resolves to this box's IP address. [autoconfig.sub1.mydomain.co.uk ↦ 1.2.3.4]
✓  autoconfig.sub1.mydomain.co.uk: TLS (SSL) certificate is signed & valid. The certificate expires on 2023-05-27.
✓  autodiscover.sub1.mydomain.co.uk: Domain resolves to this box's IP address. [autodiscover.sub1.mydomain.co.uk ↦ 1.2.3.4]
✓  autodiscover.sub1.mydomain.co.uk: TLS (SSL) certificate is signed & valid. The certificate expires on 2023-05-27.

sub1.mydomain.co.uk -- Currently:
====================================
✖  autoconfig.sub1.mydomain.co.uk: This domain should resolve to your box's IP address (A 1.2.3.4) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [timeout] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
✖  autodiscover.sub1.mydomain.co.uk: This domain should resolve to your box's IP address (A 1.2.3.4) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [Not Set] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.

sub2.mydomain.co.uk -- Previously:
========================================
✓  MTA-STS policy is present.

sub2.mydomain.co.uk -- Currently:
=======================================
✖  MTA-STS policy is missing: STSFetchResult.FETCH_ERROR

sub2.mydomain.co.uk -- Previously:
========================================
✓  autoconfig.sub2.mydomain.co.uk: Domain resolves to this box's IP address. [autoconfig.sub2.mydomain.co.uk ↦ 1.2.3.4]
✓  autoconfig.sub2.mydomain.co.uk: TLS (SSL) certificate is signed & valid. The certificate expires on 2023-05-27.
✓  autodiscover.sub2.mydomain.co.uk: Domain resolves to this box's IP address. [autodiscover.sub2.mydomain.co.uk ↦ 1.2.3.4]
✓  autodiscover.sub2.mydomain.co.uk: TLS (SSL) certificate is signed & valid. The certificate expires on 2023-05-27.

sub2.mydomain.co.uk -- Currently:
=======================================
✖  autoconfig.sub2.mydomain.co.uk: This domain should resolve to your box's IP address (A 1.2.3.4) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [timeout] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
✖  autodiscover.sub2.mydomain.co.uk: This domain should resolve to your box's IP address (A 1.2.3.4) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [Not Set] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.

The day after I will receive another email saying it’s all working perfectly. There is no real consistency to these messages and they don’t appear to have any negative impact on my ability to send/receive emails. The last one I had before today for example was on 05/04/2023 and prior to that 07/03/2023.

If I manually run the status checks on the same day the email has arrived, it always shows as perfectly fine.

MiaB is hosted on a server at my home address. I cannot see any errors in my router logs to suggest there have been any outages/issues that coincide with MiaBs errors; on the contrary my connection has always been very stable.

As mentioned it doesn’t appear to be causing any actual problems, it’s more of a curiosity why these messages arrive when there doesn’t seem to be anything wrong with my connectivity.

2

There have been reports in the past of this behaviour. It seems to be caused by failing DNS lookups, which then succeed the following day, causing the flipping messages. Indeed, the messages are in that case not pointing at a real issue.
It might be interesting to follow-up a little bit, so some questions:

  • Where/how are you hosting this?
  • What version of Mail-in-a-Box are you on?
  • And if you feel really adventurous, you might take a look at the output of sudo journalctl -u mailinabox and see if there are interesting exceptions or errors reported there.
3

Thanks for the reply.

Where/how are you hosting this?

MiaB is running in a VM on an Unraid server at my home (FTTC connection 80/20). Domain name is managed by Fasthosts with DNS records pointing to my home IP.

What version of Mail-in-a-Box are you on?

61.1

And if you feel really adventurous, you might take a look at the output of sudo journalctl -u mailinabox and see if there are interesting exceptions or errors reported there.

Other than a failed login attempt by me to the management console, there are no errors showing, and nothing at all at the time the checks are being done.

99% of the entries are along the lines of:

Apr 25 06:25:07 box.mydomain.co.uk start[2107503]: # localhost:22 SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1

4

Thanks for getting back.

Some improvements to the dns lookup of the status checks landed in this version, but apparently it does not solve for all cases. However, at this point I cannot rule out that using a home internet connection might influence this.

5

Thanks. As mentioned it’s not causing any harm apart from just being a minor irritation that the email arrives.

While it is being run on a home broadband connection, I’ve had very few issues over the years and it’s been very stable, but it’s always possible there is something there that’s just so intermittent and quick it doesn’t register in the logs.

Probably not a real solution but maybe adding some logic that, if these timeout errors occur, automatically schedule another check a few minutes later and if it fails twice, then send the email …

6

This pull request proposes some logic very similar to what you propose, except, on timeout, it is retried immediately. Perhaps it will be merged some day.

7

Thanks again. That seems quite reasonable. It’s only a minor issue for me but would be nice if those changes fixed it if/when it’s implemented. I guess time will tell. :slight_smile: