Subject: Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal
From: Vittorio Bertola <[email-masked]>
To: Viruthagiri Thirumavalavan <[email-masked]>, [email-masked]
Date: Mon, 7 Jan 2019 11:46:23 +0100 (CET)
List-Id: UTA working group mailing list <uta.ietf.org>

> Il 7 gennaio 2019 alle 9.19 Viruthagiri Thirumavalavan <[email-masked]> 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
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy