Re: [ietf-smtp] why are we reinventing mta-sts ?

Hello Daniel,

I'm the original author of this prefix proposal. So I hope you don't mind
my input here.

If you have read my responses carefully, you might have noticed that I have
no issues with DNSSEC. In fact, I want DNSSEC to become popular.  The only
thing I don't like about DNSSEC is its complexity. Apart from that, I have
nothing against DNSSEC.

In the case of MTA-STS, I don't support it for the following reasons.

(1) End users have to spend money on buying SSL certificates, buying
hosting packages and then configuring those things.

(2) Even spending an extra $5/month is a big deal in developing countries.

(3) Not all end users have knowledge about how to configure an HTTPS
server. This is the reason why most of them relying on third party mail
hosting services like Gmail for hosting their mails. They can follow simple
things like adding a DNS record. But configuring an HTTPS server is going
to be a rocket science for them.

(4) Big companies like Google and Microsoft has millions of businesses in
their pocket to distribute the MTA-STS solution. So the end result will be
SMTP have to rely on HTTPS forever.

If you still need more reasons, this thread
<https://news.ycombinator.com/item?id=19628182>has some valid points.

On Mon, Oct 7, 2019 at 2:41 PM Daniel Margolis <dmargolis=
40google.com@dmarc.ietf.org> wrote:

> I've only quickly skimmed the original thread, but it seems like the
> argument is about this magic DNS prefix for MX records that would indicate
> "this MX should offer STARTTLS", right?
>
> As John says, the new proposal also requires DNSSEC, no? It seems like the
> primary difference is that the new proposal is simpler by indicating only
> that the server supports TLS, but not what identity it presents? Why is
> that desirable?
>
> On Mon, Oct 7, 2019 at 3:56 AM John Levine <johnl@taugh.com> wrote:
>
>> In article <20191007002348.GA23742@x2.esmtp.org> you write:
>> >> What's wrong with MTS-STS defined in RFC 8461?
>> >
>> >It requires an HTTPS server, thus adding an extra service and moving
>> >the "trust" problem to CAs (AFAICT).
>>
>> I was there when we were defining MTA-STS and the people involved,
>> who work for companies that probably handle the majority of all of
>> the mail in the world, did not want it to depend on DNSSEC for
>> deployment reasons.
>>
>> See sections 2 and 10 of RFC 8461.
>>
>> If you like DNSSEC, you can publish a DANE TLSA record for your SMTP
>> server, and systems like Comcast that pay attention to DNSSEC will use
>> it to check that you support TLS and have the right cert.
>>
>>
>>
>>
>>
>> _______________________________________________
>> ietf-smtp mailing list
>> ietf-smtp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-smtp
>>
>
>
> --
> How's my emailing? http://go/dan-email-slo
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.