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…
@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
@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.
@ravenstar68 my main.cf config giving me 100% rating
smtpd_tls_protocols = TLSv1.3 TLSv1.2
smtp_tls_protocols = TLSv1.3 TLSv1.2
smtpd_tls_mandatory_protocols = TLSv1.3 TLSv1.2
smtp_tls_mandatory_protocols = TLSv1.3 TLSv1.2
tls_ssl_options = 0x40000000
smtpd_tls_eecdh_grade = ultra
tls_preempt_cipherlist = yes
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = medium
smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
smtp_tls_ciphers = $smtpd_tls_ciphers
lmtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
lmtp_tls_ciphers = $smtpd_tls_ciphers
Don’t foget to generate 4096 DH in /home/user-data/ssl/dh4096.pem
Are these changes something that could get incorporated? I have made the TLSv1.0 and TLSv1.1 but too new to MIAB to know if these will be breaking changes.
They also appear to be in PMIAB too @davness although I didn’t get any errors updating my PMIAB
I figured out most of this, but still have 1 issue left.
Part of the issue is I use DNS Made Easy for all my DNS, and my main domain is on a separate server than the MIAB server. I have been running this way fine for quite a while.
I was able to add the _mta-sts and _smtp._tls txt files fine.
Then using info from this thread:
I added the Alias firstname.lastname@example.org (using my domain name).
This worked ok it said.
But then for the TLS Certificate, for that subdomain, there was no ‘Provision’ option in the GUI, just an install option?
How to I get Let’s Encrypt to add the TLS certificate for the new subdomain on the MIAB server?
Also it did not seem to create the mta-sts.mydomain.com subdomain, the /home/user-data/www/ directory just has a ‘default’ directory and not anything else. Is the file somewhere else? It didn’t say to create that directory, it implied that it would be made when I added the alias mail account.
Let’s Encrypt did the main MIAB domain certificate fine when I first installed and has worked fine for that.
If anyone can offer some help, it would be appreciated.
@johnfl68 What is your domain?
Since there are still SMTP servers out there that send mail that don’t support TLS 1.2, and making this change would prevent people from receiving mail from those servers, I won’t incorporate those changes. In fact, we did this, and then a user reported not being able to receive mail from a sender, so we reverted it.
I’d assumed as much with such an obvious omission.
Late to the table, but I think I’d prefer to reject such mails in this day and age
I had the same problem with the missing records after upgrading to 0.5 but found that it resolved itself after a few days waiting. Each day a few DNS record would be added so no manual corrections or rerunning of setup is required. Just some patience.
I had a problem with external mail servers not being listed in the mta-sts.txt being served up via https. It looks like the one @ /var/lib/mailinabox/mta-sts.txt is used by default. Can I tweak that in the nginx config for a non-default domain to point it to a file somewhere else, perhaps in user-data or would that be considered an unsupported customization? (=
My DNS for MIAB server is an external DNS provider. What do I need to add to these records to get this error in the console fixed?
There are two domains hosted by the box and it has its hostname in one of the domains.
for example it hosts domain1.com and domain2.net and the hostname of the MIAB box is box.domain2.net.
Just not sure which records go in which dns set of entries?
Only for the MIAB host (domain1) as MX records for domain2 should point to domain 1
It should be clearly listed on the ‘External DNS’ page in the admin area.
Same for me, error has disappeared after DNS propagation.
I can confirm that no action is required, just wait for 24 to 48 hours and DNS records will propagate automatically across DNS servers and the errors will disappear. No need to issue Let’s Encrypt certificates or anything.
@ravenstar68 sorry for the late response and sorry if it appear as if I was being cocky or dumb, I’m full foss supporter and I and ourselves have a huge amount of thanks to give to @JoshData, I want to contribute in every way possible and for the future of this project, once again, sorry, I’m not native in English so that maybe got bad combined with the rush…
After using the MiaB Control Panel TLS (SSL) Certificates page to request certificates from Let’s Encrypt for the new mta-sts subdomains and allowing time for DNS propagation, the only issue reported by external validators is the lack of TLSRPT records. This external MTA-STS Validator explains: “It is defined in RFC-8460 and allows users to specify a mechanism where TLS failures can be reported automatically by affected sites.…TLSRPT is not strictly mandatory in conjunction with MTA-STS….” So, it seems that including TLSRPT records would be nice, but is not required by RFC-8460.