> > 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?
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
