Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

[Viruthagiri Thirumavalavan <[e-mail]>]

>
> There are plenty of lightweight free daemons out there that can securely
> serve static content over TLS.


Alice, Thanks for the input.

I don't think "lightweight" is the problem here. If i'm desperate about
email security I'm gonna configure the web server even if it is not
lightweight. As you know, web server and mail server are two different
things. One should not depend on another in order to work.

For example, I'm using my domain only for mailing purposes. If I have to
setup a HTTPS server to make my email secure, i'm probably ok with that.
But it's not easy for non-tech savvy user who depends on third party mail
services like Google Apps. Setting up web server, installing SSL
certificates are high level tasks for a non-tech savvy user.

IDNs use a complex encoding and there is no reason to assume the encoding
> won't occasionally include the string "26pref".


As far as I can see, the converter converts the IDN names to ASCII string.
Since the text "26pref" is already an ASCII string, it's being kept
untouched.

If you are 100% sure that IDN gonna remove the string, then I agree my
proposal has no merits and this discussion is pointless. But the question
is, are you really 100% sure that they are gonna strip that string?

Really, this is what SRV is for.  It's not hard to program, and we all
> know that mail is not the web and the time for DNS lookups (of which
> there are already at least two, more if there's multiple MX) is not in
> the critical path.  If you want to be clever, do the SRV and MX
> lookups at the same time.


In my document, I mentioned this.

*From 2031 onwards, both port 26 and 25 would function similarly. Some
server admins just prefer to deal with only the secure version. So they can
name the MX server with prefix "26only-"*

And this

*In HTTPS, you prepend the "https" in the URL like https://www.google.com
<https://www.google.com> to signal the port 443 existence.*

*In my solution you are doing the same thing. Originally I wanted to have
the "smtps" prefix. So the MX record would look like this.
smtps-mx1.example.com <http://smtps-mx1.example.com>*

*But SMTP doesn't have any redirect feature like HTTP. So I had to go for
variations like "26pref" and "26only". Thus, "port 25 not allowed"
signaling can happen during the MX server "discovery" stage itself.*

Ok John, Let's go with your SRV solution. How can server admins let the
world know that they discontinued port 25?