Date: Mon, 7 Jan 2019 11:46:23 +0100 (CET)
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Viruthagiri Thirumavalavan <giri@dombox.org>, uta@ietf.org
Message-ID: <6153128.17277.1546857983981@appsuite.open-xchange.com>
In-Reply-To: <CAOEezJS+T3pP-GqwJFeT=HGbOu1TkY6W0kyjP9_FcVsaJ=hw7A@mail.gmail.com>
References: <CAOEezJTyEf+Sn9ZqQPue1DFUSoFO211YogJ6ufYJxswWzXk=_A@mail.gmail.com>
 <20190106010828.CC431200C5ED52@ary.qy>
 <CAOEezJShOYkmy8-E+8zG=CPXxrWNcxf8q8W8MnW-v1RT0FzEWw@mail.gmail.com>
 <123cecc0-aba2-9530-c0d9-b6437f295140@domblogger.net>
 <88fad90d-24b6-fe4d-5df8-bc294c4f6b33@bluepopcorn.net>
 <CAOEezJS+T3pP-GqwJFeT=HGbOu1TkY6W0kyjP9_FcVsaJ=hw7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_17276_1590069061.1546857983975"
Importance: Medium
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/x6WyswQg9uBJe7-L9j0jWf-ajjA>
Subject: Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal
Precedence: list

------=_Part_17276_1590069061.1546857983975
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


> Il 7 gennaio 2019 alle 9.19 Viruthagiri Thirumavalavan <giri@dombox.org> ha scritto:
> 
>     Hey all, revised my draft based on the feedback I received from this thread. 
> 
>     Changelog:
> 
>     * Added starttls only support. 
>     * Provided test cases for IDN names. 
>     * Included Jim Fenton's proposal in the related projects section.
>     * No port hardcoding. Removed 26pref and 26only options. Now MX hosts can start with either "smtps-" or "starttls-" prefix
>     * Solution can be used along with STS and DANE
> 
>     https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314
> 
Hello,

I remember you from a few months ago on the DMARC-discuss list, when you tried to convince everyone that you had finally solved the problem of spam by introducing your proprietary standard "Sender Alias Domains" (where did that go?). So while I appreciate your ingenuity and willingness to approach big problems that are not completely solved yet, I must also point out that there are good reasons why those problems have not been addressed with easy solutions like the ones you propose. I would advise you to make sure that you fully appreciate the explanations that are given to you on why your proposal is fundamentally flawed, rather than just adjusting the original proposal a bit and keep posting it again.

Specifically, adding whatever semantic value to DNS hostnames or parts thereof is a non-starter for many reasons that have already been pointed out, so please stop proposing that. Moreover, the IETF does not have the power to mandate people to turn on or off specific services at a specific time, nor to change or update their implementations, neither in theory (in regulatory terms) nor in practice, so any proposal should be backwards compatible with the status quo for an indefinite amount of time. So, in the end, your solution fails to prevent downgrade attacks, but even if it did, they have been addressed with two other technologies already (MTA-STS and DANE), so there is really no reason to develop a third one unless you can provide a compelling reason or use case in which both the other two do not work.

On that point, you are right when you say that big systems that host mail for thousands or millions of domains are unlikely to ever implement MTA-STS, as that requires to activate one HTTP service per each domain - but we already have DANE for that case.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

------=_Part_17276_1590069061.1546857983975
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   <br>
  </div>
  <blockquote type="cite">
   Il 7 gennaio 2019 alle 9.19 Viruthagiri Thirumavalavan &lt;giri@dombox.org&gt; ha scritto: 
   <br>
   <br>
   <div dir="ltr">
    <div dir="ltr">
     Hey all, revised my draft based on the feedback I received from this thread.&nbsp;
     <div>
      <br>
     </div>
     <div>
      Changelog:
     </div>
     <div>
      <br>
     </div>
     <div>
      * Added starttls only support.&nbsp;
     </div>
     <div>
      * Provided test cases for IDN names.&nbsp;
     </div>
     <div>
      * Included Jim Fenton's proposal in the related projects section.
     </div>
     <div>
      * No port hardcoding. Removed 26pref and 26only options. Now MX hosts can start with either "smtps-" or "starttls-" prefix
     </div>
     <div>
      * Solution can be used along with STS and DANE 
      <br>
     </div>
     <div>
      <br>
     </div>
     <div>
      <a href="https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314">https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314</a>
      <br>
     </div>
    </div>
   </div>
  </blockquote>
  <div>
   Hello,
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   I remember you from a few months ago on the DMARC-discuss list, when you tried to convince everyone that you had finally solved the problem of spam by introducing your proprietary standard "Sender Alias Domains" (where did that go?). So while I appreciate your ingenuity and willingness to approach big problems that are not completely solved yet, I must also point out that there are good reasons why those problems have not been addressed with easy solutions like the ones you propose. I would advise you to make sure that you fully appreciate the explanations that are given to you on why your proposal is fundamentally flawed, rather than just adjusting the original proposal a bit and keep posting it again.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   Specifically, adding whatever semantic value to DNS hostnames or parts thereof is a non-starter for many reasons that have already been pointed out, so please stop proposing that. Moreover, the IETF does not have the power to mandate people to turn on or off specific services at a specific time, nor to change or update their implementations, neither in theory (in regulatory terms) nor in practice, so any proposal should be backwards compatible with the status quo for an indefinite amount of time. So, in the end, your solution fails to prevent downgrade attacks, but even if it did, they have been addressed with two other technologies already (MTA-STS and DANE), so there is really no reason to develop a third one unless you can provide a compelling reason or use case in which both the other two do not work.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   On that point, you are right when you say that big systems that host mail for thousands or millions of domains are unlikely to ever implement MTA-STS, as that requires to activate one HTTP service per each domain - but we already have DANE for that case.
   <br>
  </div>
  <div>
   <br>
  </div>
  <div>
   Regards,
  </div>
  <div class="io-ox-signature">
   <p>-- <br class=""></p>
   <pre class="">Vittorio Bertola | Head of Policy &amp; Innovation, Open-Xchange<br><a href="mailto:vittorio.bertola@open-xchange.com">vittorio.bertola@open-xchange.com</a> <br>Office @ Via Treviso 12, 10144 Torino, Italy</pre>
  </div> 
 </body>
</html>
------=_Part_17276_1590069061.1546857983975--