This would improve our email security by somewhat mitigating downgrade attacks which block the STARTTLS SMTP command between sending MTAs and the SRCF's MX server, currently mx.cam.ac.uk. It would also mitigate attacks in which DNS queries for srcf.net. IN MX are tampered with (in situations where the recursive resolver doesn't also validate DNSSEC). Note that this secures inbound mail only and doesn't affect outgoing messages in the way SPF/DKIM/DMARC do.
Alternatives considered
Since the SRCF does not have its own MX server, publishing DANE records isn't possible as they'd have to go in the main cam.ac.uk. zone. An MTA-STS policy is something the SRCF could implement entirely on its own.
MTA-STS isn't perfect (in particular it relies on TOFU and lengthy caching), but it is a good forward step IMHO.
Project/idea summary
The SRCF should strongly consider publishing a MTA-STS policy for its domain(s).
https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/using-mta-sts-to-protect-the-privacy-of-your-emails
Motivation
This would improve our email security by somewhat mitigating downgrade attacks which block the
STARTTLSSMTP command between sending MTAs and the SRCF's MX server, currentlymx.cam.ac.uk. It would also mitigate attacks in which DNS queries forsrcf.net. IN MXare tampered with (in situations where the recursive resolver doesn't also validate DNSSEC). Note that this secures inbound mail only and doesn't affect outgoing messages in the way SPF/DKIM/DMARC do.Alternatives considered
Since the SRCF does not have its own MX server, publishing DANE records isn't possible as they'd have to go in the main
cam.ac.uk.zone. An MTA-STS policy is something the SRCF could implement entirely on its own.MTA-STS isn't perfect (in particular it relies on TOFU and lengthy caching), but it is a good forward step IMHO.