> > For one thing, it doesn't work with IDNs.
I just tested "26pref-español.mydomain.com <http://xn--26pref-espaol-skb.mydomain.com>" in this page <https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-conversion-tool/index.xhtml?loc=en_US> .. The output looks like "xn--26pref-espaol-skb.mydomain.com". So instead of "if string starts with", we should go for "if string contains". On Sun, Jan 6, 2019 at 5:48 AM Viruthagiri Thirumavalavan <[email protected]> wrote: > Thanks guys. Appreciate the responses. > > >> You seem to be part-duplicating the intent of a DNS SRV record. >> Wouldn't the definition of a service name "smtps" with no hardcoded >> port number (per RFC 6335), and the use of SRV per RFC 2782, do the >> job and be preferred to an ad-hoc method? > > > My intention was avoiding those extra DNS lookups. As a developer, I would > rather prefer to have a simple "if string starts with" check, rather than > performing a DNS lookup like "_smtps._tcp.example.com". The majority not > gonna have that record. So we are wasting the lookups there. > > This adds complexity, without solving any problems. I'm afraid >> this proposal has no merit. >> * The attacker can just as easily block connections to port 26, >> as filter out STARTTLS. >> * This in no way addresses the authentication issues. > > > I already addressed both issues in the document. Refer "Deprecation" and > "Security Considerations" section. My proposal is all about deprecating > "Plain Text" in port 25. > > This sort of thing, encoding stuff in domain names, is a non-starter. >> For one thing, it doesn't work with IDNs. > > > You got me here. I don't have any experience with IDN. So I can't argue > with this one. I hope we can atleast use numbers as prefix if not english > characters. If no prefix possible in IDN, then yes it's a non-starter > > For another, mail servers >> don't know what their names are and is quite common to point hundreds >> or thousands of MX records at the same server if it handles a lot of >> client mail domains. What happens when (not if) they aren't >> consistent? > > > I'm not following you. I hope you are talking about third party mail > hosting services like Google Apps. If yes, then I addressed that in the > "Migration => Third Party Hosted" section. > > Also, more practically, anything like this requires a change to the >> way that mail clients look for mail servers > > > This is what I mentioned in my document. > > *The "26pref" says "We prefer if you connect to our SMTPS in port 26. But > we also accept mails in port 25".* > > *So now SMTP clients can check for whether MX server starts with the > string "26pref". If it starts with that string, then the clients gonna > connect to port 26 (smtps). A normal client that doesn't know what "26pref" > stands for gonna connect to port 25 as usual.* > > Thanks > > On Sun, Jan 6, 2019 at 2:52 AM John Levine <[email protected]> wrote: > >> In article <CAOEezJSQ= >> [email protected]> you write: >> >I'm proposing a very simple solution. It's actually dead simple. So i'm >> not >> >really sure whether it was proposed before and got rejected for some >> >reasons or you guys really missed that one. >> >> This sort of thing, encoding stuff in domain names, is a non-starter. >> For one thing, it doesn't work with IDNs. For another, mail servers >> don't know what their names are and is quite common to point hundreds >> or thousands of MX records at the same server if it handles a lot of >> client mail domains. What happens when (not if) they aren't >> consistent? >> >> Also, more practically, anything like this requires a change to the >> way that mail clients look for mail servers, and if you're going to >> change, change to SRV which is already well defined and in use in >> other applications such as SIP. >> >> -- >> Regards, >> John Levine, [email protected], Primary Perpetrator of "The Internet for >> Dummies", >> Please consider the environment before reading this e-mail. https://jl.ly >> > > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
