Just upgraded,
and no error during the upgrade, but now every domain name has error msg:
MTA-STS policy is missing: STSFetchResult.NONE
V0.50
https://github.com/mail-in-a-box/mailinabox/releases/tag/v0.50
3 Likes
I’m seeing that error twice also, as the only errors on my system status checks page, for my one email domain system. I just upgraded from 48 to 50, with no errors noted there.
A missing MTA-STS policy won’t affect incoming mail compared to the previous version of Mail-in-a-Box but indicates that the new MTA-STS record (which adds security for incoming mail) isn’t present. This might be a normal DNS propagation issue. Or maybe after an upgrade we don’t immediately publish updated DNS records. Can you report back tomorrow if the error is still there?
I upgraded from 0.42b to 0.50 and it happens too, but I think is the same that Josh told you, the DNS propagation and you need to wait some time (The TXT TTL in MIAB is 1800, in max one hour should be OK)
You can use this online tool: https://www.whatsmydns.net
Enter _mta-sts.<DOMAIN> Changing <DOMAIN> with your domain, and choose TXT record. You will see the response in several DNS public servers.
You can query also directly to your box with: dig +short txt _mta-sts.<YourDomain>
I add a external tool to check STS: https://esmtp.email/tools/mta-sts
This web inform other DNS register that MiaB won’t have: _smtp._tls
In my case I have banned web acces to only my GeoIP country, and is normal that the web STS check will fail.
1 Like
I have found a posible problem condition. If you have a wildcard register like *.<DOMAIN> , the new STS register don’t response in MiaB DNS server, even you query dig txt DOMAIN @YourBOX
In my case the solution was delete your domain wildcard and then create again. For me it solves if you add the wildcard as the last entry added.
I use wildcard to add TXT for spf in *.YourDomain entry to avoid spammers using subdomains of my domain.
In my case it was due to a lack of certificates. After provisioning, the error was gone.
I see, my " TLS (SSL) Certificates" page on the BOX shows that the certificates for the mta-sts.box.domain.name have been provisioned,
but when I look up my certificate “mta-sts.box.” entries are missing in “Certificate Subject Alt Names”
echo | openssl s_client -connect box.domain.name:443 2>/dev/null | openssl x509 -noout -ext subjectAltName
or the whole cert
echo | openssl s_client -connect box.domain.name:443 2>/dev/null | openssl x509 -noout -text
running: ~/mailinabox/management/ssl_certificates.py
would skip all the already provisioned certs and not add the mta-sts.box. entries 
“_mta-sts” record is automatically generated by mailinabox for “box.yourdomain.com” but there should be following records to be added (you can do it manually through Custom DNS in Control Panel on on your DNS server):
_mta-sts.yourdomain.com IN TXT v=STSv1; id=xxxxxxxxxx
_smtp._tls.yourdomain.com IN TXT v=TLSRPTv1; rua=mailto:admin@yourdomain.com
and _smtp._tls.box.yourdomain.com IN TXT like above…
where id= can be a timestamp for example 20200826153000
Allow time to propagate before checking.
1 Like
Topic error has disappeared now. Tks
for me too, the https://mta-sts.box.domain.com/ and https://mta-sts.domain.com/ tls certificates we’re missing, I provisioned them with Let’s encrypt button but the error still appears in the check list for both, and cannot send email to other domains.
create following records (you can do it manually through Custom DNS in Control Panel or on your own DNS server):
_mta-sts.yourdomain.com IN TXT v=STSv1; id=xxxxxxxxxx
_smtp._tls.yourdomain.com IN TXT v=TLSRPTv1; rua=mailto:admin@yourdomain.com
and _smtp._tls.box.yourdomain.com IN TXT like above…
where id= can be a timestamp for example 20200826153000
Allow time to propagate before checking.
You can use MTA-STS Validator at https://aykevl.nl/apps/mta-sts/
1 Like
Rerunning the upgrade solved my mta-sts dns issue, after having to re-provision the LE certs for mta-sts I got the same error, but updating again appeared to create the required dns records.
1 Like
This was my experience too.
I upgraded. The provisioned the TLS (SSL) certificates. Then ran the upgrade script again.
Et voila.
2 Likes
I found the following too.
- The DNS entry for _mta-sts. was present in the zone, but for some reason failed to propogate out to recursive resolvers initially.
- The certificate for mat-sts. had to be manually provisioned by myself using the Admin console.
- There was no _smtp._tls. TXT record. I had to manually enter this.
I initially ran the updatedns.py script and then rebooted following the provisioning of the mta-sts certificate and that seemed to fix the issue.
HOWEVER
I do note that when I tested at hardenize - https://www.hardenize.com/ I got a number of warnings
- Missing \r\n from the ends of some of the lines of the mta-sts.txt file
- Postfix was still accepting TLS 1.0 and 1.1 connections as well as failing to enforce preferred cipher orders.
I’ve managed to fix the latter by editing my main.cf file to change the following lines:
smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
tls_preempt_cipherlist=yes
smtp_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
It’s evidently not enough just to exclude the defunct TLS type in the smtpd_tls_mandatory_protocols and smtp_tls_mandatory_protocols lines.
Tim
Can confirm, by just rerunning the upgrade commands the errors disappeared.
why should we configure this manually? isn’t safer to be all automatic by miab?
Same experience here. Provision the certificates from Lets Encrypt and then run the upgrade again.
@BORIKKEN21 because you want it working? It’s a workaround until it’s getting fixed. MIAB is not a product you buy and expect everything will be working just 100%. It’s a development project…
@DANE @BORIKKEN21 @ravenstar68 @pwmxx Errors disappeared from log doesn’t mean everything is working. You should check mta-sts configuration with external valuator.
@ravenstar68 you also need to order ciphers in main.cf from strongest to weakest and disable weak ciphers. You can use recommended ciphers by Mozilla Foundation and validate with Hardenize or Internet.nl
2 Likes
@ondrej - Thanks for that. The strongest ciphers already appear to be listed first, although the weak ciphers are still included further down the list, Hardenize was much happier with the result once I’d changes tls_preempt_cipherlist to yes.
@BORIKKEN21 - In an ideal world everything would work perfectly first time. MIAB is a labour of love by @JoshData, it’s good but it’s not necessarily perfect to everyone’s standards. Josh has done a good job. However if you are running a mail server it’s always a good idea to try and understand what’s going on under the hood.
Tim
1 Like