It turns out that we need to host the policy file on a specific subdomain, rather than the root domain. I don't think there can be any harm from serving it from the root domain too, so I'm going to leave that in place (it seems possible we'll want the .well-known directory at some point anyway). Note that we do actually need to respond on the subdomain too -- we can't just redirect (as was my first approach).
These changes are actually already live, along with rotating the TLS certificate to account for the new domain this adds. Would still be good to get some eyes on this.
Summary
It turns out that we need to host the policy file on a specific subdomain, rather than the root domain. I don't think there can be any harm from serving it from the root domain too, so I'm going to leave that in place (it seems possible we'll want the .well-known directory at some point anyway). Note that we do actually need to respond on the subdomain too -- we can't just redirect (as was my first approach).
These changes are actually already live, along with rotating the TLS certificate to account for the new domain this adds. Would still be good to get some eyes on this.
Code review
Testing
Already live & validated as there didn't seem to be great ways to validate the interaction with other servers in other ways. (i.e: https://mta-sts.studentrobotics.org/.well-known/mta-sts.txt works) Example online tester: https://www.mailhardener.com/tools/mta-sts-validator?domain=studentrobotics.org