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