Except it’s not like let’s encrypt at all. This appears to test your mail server for starttls functionality, but it doesn’t issue certs or anything like that.
(Edit: in addition to the site tester that you noticed, there is also a public policy list and some forthcoming tools to enforce STARTTLS on the client MTA side when delivering e-mail, preventing downgrade and MITM attacks.)
However, you can also use Let's Encrypt to make this more useful by getting a publicly-trusted certificate for the TLS service on your mail server, and then listing your mail server with this list!
The introductions my colleagues posted about this today are at
https://www.eff.org/deeplinks/2018/06/announcing-starttls-ev...
https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st...
which will hopefully give a clearer explanation of what the service is meant for.
SSL is not mandatory on either port 25 or 587, and SSL can not be made mandatory if you follow the RFCs (it can be made mandatory if you tweak your MTA, but you may lose some mail). Advertising for SSL over DNS means you trust the DNS records - which you shouldn't without DNSSEC. Even with it, there can be workarounds that in practice will allow MITMs.
The only real solution is making SSL mandatory, and doing SMTP over SSL as in the good old days of using stunnel on port 465 to decrypt, then netcat to forward the output to the MTA running on localhost:25
But that is not standard. Maybe the efforts would be better invested by changing the standards to have a port where SMTP can not happen at all without SSL - just like port 465 was, over 10 years ago.
I'm well-aware of the RFC difficulty, but I don't think that the current approach of STARTTLS Everywhere is really a problem because it's effectively opt-in on both ends. The enforcement is requested by the receiving side and then implemented by the sending side.
* The receiving MTA has to proactively choose to be listed.
* The sending MTA has to proactively choose to make use of the list.
So, with the current version of STARTTLS Everywhere, only sites that deliberately choose to enforce STARTTLS will do so, and they will only do it when communicating with sites that have specifically asked them to enforce it! This would only be an RFC violation if we thought that the RFC meant to categorically forbid sites from separately agreeing to a stricter security policy.
This approach might have its scalability limitations, but I won't try to speak for my colleagues about any future steps.
The problem is not the MTA who will chose to be listed, but those who won't be listed - the immense majority. "Scalability limitation" is certainly a more polite way to say that.
I'm sorry if my message was too blunt, but I am not sure it was worth downvoting my technical explanation just for this.
The HSTS preload list also has a huge scalability problem, but it's also improved the situation about HTTPS downgrades a lot!