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

[Viruthagiri Thirumavalavan <[e-mail]>]

>
> 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 <[e-mail]>
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 <[e-mail]> wrote:
>
>> In article <CAOEezJSQ=
>> [e-mail]> 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, [e-mail], 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.