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 Дилян Палаузов
<dilyan(_dot_)palauzov(_at_)aegee(_dot_)org>
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp