To the OP - what's the point of hiding the hostname in the smtp banner? You already know from the dns. Concerned about the MTA version? You can configure postfix to claim it is exchange or avian carrier for that matter
I was concerned about the Brand name right next to the 220 hostname example I posted earlier. I thought it would offer little more privacy. I was wrong. So - given that multiple people have explained to you on the ietf-smtp list
that there's no really sensitive info before STARTTLS, what *exactly* does your proposal buy us? What *real* problem is port 26 fixing? And is this something that *you* think is a problem, or that somebody who runs an actual production mail system thinks is a problem?
Thanks Mr. Kletnieks, Nice to meet you again. [To everyone else - he is one of the nicest person who provided suggestions in ietf-smtp] When I proposed I thought this was an issue. But seem like it's not. What I'm looking for here is will there be any additional pros if we introduce Implicit TLS? Pros of introducing Implicit TLS: + Falls under Best Practices + Sets an early date to deprecate Opportunistic TLS in the future. (e.g. 20 years from now) + Seems like it's what the world wants. Cons of introducing Implicit TLS: - Wastes a port - ISP needs to add little code to block port 26 Well, the summary on the ietf-smtp list was that the new port doesn't
actually buy you anything unless you have DANE, and once you have DANE, the new port doesn't add anything. The conclusion is that we should be deploying DANE more rather than burning a port. Not sure why you expect to hear much differently from NANOG.
I improved my proposal a lot based on feedback I received from people like you. My proposal doesn't rely on DANE. Only DNSSEC. Even for that part, it doesn't mandates that. When example.com mails are third party hosted, example.com needs DNSSEC and third party mail servers (e.g. Google) needs DNSSEC+DANE. But google seem like it's not interested in DNSSEC. Thus Google provides a DANE alternative called MTA-STS. Let's say my domain supports DNSSEC. If my domain mails are hosted in Google, then I have no other way other than going for MTA-STS. MTA-STS needs another https server just for the sake of mail security. My proposal just changes that. Google gonna name their MX servers with starttls- prefix. And now example.com can protect MX record spoofing via DNSSEC. My point is, the signalling mechanism is handed over to third party mail providers like Google in DANE. My solution embeds the signalling mechanism in the hostname. Thus google don't have to evangelise MTA-STS to their millions of customers. Please correct me if I'm wrong with those statements On Sat, Jan 12, 2019 at 10:36 AM <valdis.kletnieks@vt.edu> wrote:
On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said:
But I still want the future of email to adopt Implicit TLS. So someday we can kill Opportunistic TLS. I already lost the case for security. So my smtps part of the proposal not gonna fly. I'm just here to learn whether Implicit TLS can offer anything better than Opportunistic TLS that's worth wasting a port.
Well, the summary on the ietf-smtp list was that the new port doesn't actually buy you anything unless you have DANE, and once you have DANE, the new port doesn't add anything.
The conclusion is that we should be deploying DANE more rather than burning a port.
Not sure why you expect to hear much differently from NANOG.
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.