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

[Viruthagiri Thirumavalavan <[e-mail]>]

>
> Much more people know how to configure an HTTPS server, than to configure
> a SMTP server (with STARTTLS).  So configuring
> HTTPS is not an obstacle.  Since, soon or late a mail server operator will
> want to reject emails that fail DMARC
> validation, the operator will have to learn DKIM.  Then set some custom
> email rules, AV/AS and so on.  Setting up HTTPS
> (and a web-based mail client) looks trivial compared to the remaining
> pieces.


We both use a different demographic to define "end user" for MTA-STS. The
way you see it, an end user is a "mail server operator".  The way I see it,
an end user is a "small business" who hosts their mails in a third party
mail service like Gmail. Configuring an HTTPS server is not going to be
easy for such small businesses.

This comment <https://news.ycombinator.com/item?id=19629569> portrays that
part more clearly.

I'd like to be wrong, but with the nature of this standard, I don't expect
> heavy adoption. If a person is deploying G Suite or Office 365 or similar,
> they get asked to setup MX records, TXT for SPF, possibly DKIM and so on.
> If I could create a record that says "use the policy Microsoft/Google
> publish", it would be a no brainer. And it would take off because, much
> like SPF, these groups can just add it to their onboarding checklist.
> As soon as you say "deploy an end point on your domain", it falls in the
> too hard basket for unimportant domains. Moreover, in a corporate situation
> the people running mail have no involvement in web endpoints. For the mail
> domains I professionally manage, that falls into the domain of another
> department, and the people involved in running web endpoints are going to
> say something like "if it was important, Wordpress would do it already for
> us".


On Mon, Oct 7, 2019 at 9:09 PM Дилян Палаузов <[e-mail]>
wrote:

> Hello,
>
> On Mon, 2019-10-07 at 18:55 +0530, Viruthagiri Thirumavalavan wrote:
> > (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.
> >
>
> Much more people know how to configure an HTTPS server, than to configure
> a SMTP server (with STARTTLS).  So configuring
> HTTPS is not an obstacle.  Since, soon or late a mail server operator will
> want to reject emails that fail DMARC
> validation, the operator will have to learn DKIM.  Then set some custom
> email rules, AV/AS and so on.  Setting up HTTPS
> (and a web-based mail client) looks trivial compared to the remaining
> pieces.
>
> The HSTS (http strict transport security) preload list,
> https://hstspreload.org/, is knowledge in HTTP browsers, about
> sites, which serve content explicitly over HTTPS.  Browsers use the
> knowledge and do not contact the hosts under the
> listed domains over pure HTTP.
>
> Similar to it, there is a MTA-STS (smtp strict transport security) preload
> list: a set of hosts, which can serve SMTP
> over TLS.  The list is hosted at https://starttls-everywhere.org/ .  This
> list functions just like HSTS preload list,
> but for port 25.
>
> Talking about SMTP and TLS is bi-fold.  There are incoming and outgoing
> connections.  Depending on the MTA, setting up a
> MTA that applies DANE for outgoing connections can be done very easily, so
> in the context of outgoing connections,
> utilizing DANE/DNSSEC can be easier than MTA-STS.
>
> Installing the MTA-STS preload list on the own MTA, and using it for
> outgoing connections, can be easier than
> configuring MTA-STS for outgoing connections.
>
> Deploying/enforcing DANE for outgoing connections is equally hard compared
> to deploying MTA-STS for outgoing
> connections, when the used MTA offers neither features.
>
> To sum up, the options in the MTA are:
> * for outgoing connections:
>   - check MTA-STS (without necessary publishing own MTA-STS records)
>   - check DANE (without having deployed DNSSEC for the own domain)
>   - check the STARTTLS-everywhere preload list for the destination host
>   - consider sending your own certificate during establishing the TLS
> tunnel (nearly nobody does this)
>
> * for incoming connections:
>   - publish MTA-STS records
>   - publish DANE records, once DNSSEC is set up
>   - add an entry in the MTA-STS preload list
>
> * for both: speak TLS 1.3 .
>
> What are the pros and cons of sending the certificate of the SMTP client
> to the SMTP server, during STARTTLS?
>
> Regards
>   Дилян
>
>

-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.