> Il 7 gennaio 2019 alle 9.19 Viruthagiri Thirumavalavan <[email protected]> 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 protected] mailto:[email protected] 
Office @ Via Treviso 12, 10144 Torino, Italy
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to