The situation with SMPTS and port 465 is a fun one. By my understanding, at present, implicit TLS for submission isn't standard. Now, a lot of mail server operators listen on port 465 for SMTPS anyway, because very breifly, that was the standard port for such. But there are other operators who are stickler for the letter of the standard, and when asked to support SMTPS on port 465, respond with "That's not standard. STARTTLS on 587 is. Use STARTTLS." I will confess to having been one of those operators in the past. Reflecting, I suspect that was at least partly because in insisting on strict standard compliance, I cut down on the amount of spam I had to deal with (you would be amazed at the sheer volume of poorly coded bots that imediately throw a LOGIN or MESSAGE FROM at you upon establishing a connection, not even bothering to forge a HELO or EHLO).

I totally support RFC 8314's attempt to standardize existing practice, and get port 465 officialy recognized. https://datatracker.ietf.org/doc/html/rfc8314 Once done, what is "standard" will no longer be an excuse. Though, updating out-of-support middleboxen will probably still take a while.

I was under the impression 8314 was a "done deal". IANA have listed 465 as submission over TLS since december 2017.

(The previous iteration was submission over SSL in the late 90s on the same port.)

Similarly, I have my personal SSH server configured to only accept "modern" crypto. A fair number of attacking clients fail to negotiate a cipher!

I recently switched my SSH servers to only listen to IPv6. They're still on port 22, and still pointed to by DNS, yet, while they received bot connection attempts every few seconds when listening for IPv4, they haven't received a single bot connection attempt in the last week since I made the switch.

Bots apparently simply don't bother with IPv6.

Enumeration of all IPv4 is easy. Enumeration of all DNS entries is hard to impossible. Enumeration of all IPv6 is impossible.

> Enumeration of all IPv6 is impossible.

Though do take note of RFC 7707, "Network Reconnaissance in IPv6 Networks":

   IPv6 offers a much larger address space than that of its IPv4
   counterpart.  An IPv6 subnet of size /64 can (in theory) accommodate
   approximately 1.844 * 10^19 hosts, thus resulting in a much lower
   host density (#hosts/#addresses) than is typical in IPv4 networks,
   where a site typically has 65,000 or fewer unique addresses.  As a
   result, it is widely assumed that it would take a tremendous effort
   to perform address-scanning attacks against IPv6 networks; therefore,
   IPv6 address-scanning attacks have been considered unfeasible.  This
   document formally obsoletes RFC 5157, which first discussed this
   assumption, by providing further analysis on how traditional address-
   scanning techniques apply to IPv6 networks and exploring some
   additional techniques that can be employed for IPv6 network
   reconnaissance.

* https://datatracker.ietf.org/doc/html/rfc7707

If we move to ipv6 majorly I suspect reflex scanning will become more of a thing (see a connection from X, scan X).

IPv4 is trivial to enumerate. IPv6 is not.

Guess how most SSH-scanning bots find targets?

Probably saves them time. You are not a soft target. What incentive do they have to add support when it only gains them access to more hardened systems that most likely are not vulnerable to their next phase.

STARTTLS and its ilk are what happens when technology companies (& their minions) are pussies. It has been clear for decades that secure e-mail transport would be a good idea, but not if we had to actually upgrade software / systems to get it. This bullshit is so endemic that Google Mail has actually released two new standards in 2019, that depend on two other protocol stacks, just to advertise to SMTP servers that they support secure mail.

Thankfully, in 2018 someone had the balls to release RFC8314, which explicitly obsoletes cleartext for MUA <-> MSS <-> MAS mail. So why did Google release standards in 2019 that presume that some servers still won't talk TLS? My guess is they're terrified someone won't send them mail, and they'd lose some of that sweet sweet analytics money.

We clearly have an endemic problem in our technology culture related to breaking changes in order to fix shit. This is going to keep happening, unless we come up with new industry principles and practices to enforce breaking upgrades of legacy systems. If your system doesn't have a sunset date of less than 8 years, it should be considered broken out of the box. If it doesn't expect major feature overhaul after 4 years, it should be abandoned in favor of a system that does. Not having zero-downtime upgrades and rollbacks should be a non-starter too. Basically we need a "12 factor app" for protocols and systems.

I'm OK with StartTLS. What I think is missing is a DNS record that mail servers cache for a long time, similar to HSTS that says you MUST use encryption for this domain. Probably also a variation to the record to say to validate the cert chain. This would align with an existing capability in postfix that allows you to specify which domains must be encrypted, or mandatory cert chain validation and to what level. At least I think this would be the easiest path to a better security stance and probably the simplest to implement given the myriad of email servers, clients and client libraries. Perfect is the enemy of good, or so they say. Below is from postfix. There are many more options.

  smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

  example.net           secure  match=example.net:.example.net
  anotherexample.net    may     match=anotherexample.com:.anotherexample.com

It sounds like you're asking for [MTA-STS](https://dmarcian.com/mta-sts/)

"MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers."(..)

"The MTA-STS protocol works by having a DNS record that tells mail servers to fetch a policy file via HTTPS from a defined subdomain. This file contains a list of the receiver’s mail servers which are authenticated and approved to receive the messages and also what policy to apply to inbound messages."

Maybe. Any time we ask a library or client to do HTTP fetches when it historically only did SMTP I become less optimistic about adoption. There are obvious easy wins like Thunderbird and Outlook and those could potentially use a plugin or add-on. Maybe that could be a good start and good enough.

IIRC AWS SES has always worked this way. I remember complaining years ago it wasn't compatible with Go's SMTP library for that reason(it expected STARTTLS).

Somewhat OT: What is Meddler-in-the-Middle? I can’t find anything about it, is it just another term for MitM, or is it more nuanced?

It's probably just a gender-neutral term that still begins with M, so "MitM" still makes sense to use as an acronym (yes, grammar nerds, I pronounce it as "mittem", don't say it's an initialism).

I have no idea what the actual answer is, and instead it seems several posts about it got downvoted. Sincerely, what the fuck? Is this some secret code that can’t be discussed?

Meddler is probably just more precise then Man.

Terrible choice, as "Meddler-in-the-Middle" yields some sort of style of teaching when searched.

man-in-the-middle could be only spying... messing-in-the-middle implies something else

> How important is this

This should be at the top of the post honestly

someone should tell the openbsd guys https://github.com/OpenSMTPD/OpenSMTPD/issues/451 who explicitly tell certain users to use starttls