
RFC 8314: Use of Transport Layer Security for Email Submission and Access - okket
https://tools.ietf.org/html/rfc8314
======
korethr
So reading this, this attempts to standardize what I understood to be best
practice last time I ran a mail server - TLS required for submission and
access. I see this as a good thing.

But this doesn't seem to touch on transmission between email servers at all,
and that needs to be addressed as well. Email can be submitted protected by
TLS, but if it has to cross the Internet in the clear to reach its recipient,
then all you've succeeded in doing with submission/access TLS is prevented
your user's login credentials from leaking. You've not done much to protect
the confidentiality of your user's correspondence. Understand, I'm not
denigrating the importance of TLS for submission and access, but it's also not
the whole picture.

Yes, you _can_ set your SMTP server to opportunistically use TLS when the
other connecting SMTP server supports it as well, but not all SMTP servers do.
Mandating TLS makes those servers that don't effectively unreachable. I seem
to recall Facebook doing a study about it. The Postfix documentation warns
about it as well.

I'm not sure I have a good solution here, other than something akin to the
linked RFC: a proposed standard that gives a deprecation/sunset period to
transition to mandatory TLS. The problem then, is getting majority compliance
during that period. If the IPv6 transition is any indication, that's likely to
be an uphill battle, as mandatory TLS between SMTP servers would break a
rather large installed base that's presently working just fine.

~~~
3pt14159
The solution here is for Gmail and a few other large providers to announce a
date where they will no longer send or accept email from insecure servers.
This sounds drastic, but it's not. I've seen military contractors and patent
attorneys sending email and attachments with _no security at all_. We need to
stop pretending that security doesn't matter.

~~~
bryankeithmoore
For the case of mail submission, there is a lot of legacy hardware/firmware
out there still in use that simply doesn't support TLS, and is mission-
critical, and is likely to become obsolete before anyone upgrades it. A lot of
that traffic is considered nonsensitive by those who need it so trying to
force them to be secure isn't going to go over well. Despite that, RFC 8314
recommends that MSPs deprecate cleartext submission and mail access, but it
doesn't specify a timetable because the situations vary too widely from one
provider to another.

For message relaying, your proposal might indeed work. The vast majority of
inter-domain mail traffic goes through a very small number of providers. No
mail provider can afford to not be able to exchange mail with gmail, or
office365, or ...

~~~
3pt14159
This type of thinking is how we get ants.

It is trivial to set up a mail server with TLS and if you don't have fucking
TLS bounce it through a protocol upgrade server. If you understood the type of
secrets that are getting trivially intercepted you'd realize that a couple
hard days for a couple of lazy sys admins is a tiny price to pay for the
drastic increase in security.

People are literally getting killed because we're so fucking lazy. Even three
letter agencies are sending mail without TLS, this is madness.

------
leggomylibro
Fun fact, the OSI network stack (which wound up losing out to TCP/IP) defined
a 'presentation' layer which was meant to handle things like compression and
encryption in a way that was transparent to the application logic 'above' it:

[https://en.wikipedia.org/wiki/OSI_model](https://en.wikipedia.org/wiki/OSI_model)

~~~
tptacek
An architectural counterpoint would be David Clark's Application Layer Framing
paper:

[https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/paper...](https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/papers/alf.pdf)

------
marcosdumay
So, is IANA going along with registering the port 465 this time, or it will
only be another case of "somebody tries to do the right thing; stupid
bureaucracy insists it's wrong; case closed"?

~~~
dhx
IANA has already assigned TCP port 465 for "submissions" as described by
RFC8314. See [https://www.iana.org/assignments/service-names-port-
numbers/...](https://www.iana.org/assignments/service-names-port-
numbers/service-names-port-numbers.xhtml?&page=9)

The other service already assigned TCP port 465 was URL Rendezvous Directory
for SSM (URD).

------
peterwwillis
Email is about to get a lot less reliable.

~~~
ts4z
This has been status quo stuff for basically the last ten years. This will be
fine.

~~~
peterwwillis
No it hasn't. "Optional" has been the status quo, meaning a lot of shit
remained broken. "Mandatory" means everyone now has to deal with all the
broken shit, and the stuff that re-breaks, and the stuff that gets exploited,
on and on ad infinitum. This is _guaranteed_ to make less reliable services.

~~~
bryankeithmoore
Nothing gets fixed until people realize it's broken. And yet, it's also true
that using TLS for mail submission and access has been best common practice
for several years, with most providers specifying TLS in their connection
instructions and some even deprecating cleartext. This RFC might result in
more service calls as users start being told their connections aren't secure,
but it also tells providers what to do to fix the problem.

------
SheinhardtWigCo
Email itself ought to be Considered Obsolete. It’s about time for a
replacement based on decentralized privacy-preserving protocols like Matrix
and IPFS.

~~~
pmilot
How is TLS email not decentralized and/or privacy-preserving?

~~~
SheinhardtWigCo
The answer is in the title: TLS _for Email Submission and Access_

Email providers can still read your email.

~~~
jmiserez
You don't need an email provider, you can just set up a mail server on your
own computer. If the person you are sending your mail to also has their own
mail server you send it directly to them without any provider every seeing it.

EDIT: Yes I know... It's not trivial to setup and keep running, "own computer"
might need to mean hosted somewhere (VPS, datacenter, etc), and all your
contacts might also need to setup mail servers because providers like Gmail
might reject your mails. In the end it might not be worth your time, but
there's absolutely no _technical_ reason why you'd _need_ a mail provider for
emails.

~~~
ryan-c
> You don't need an email provider, you can just set up a mail server on your
> own computer.

Not really. It's not possible to send mail from a dynamic IP at all, and there
is a lot of technical minutia to not get thrown in the spam folder for major
providers. In fact, many major providers simply assume mail sent from an
unfamiliar domain and/or IP is spam by default, and you will have to contact
them to ask for permission to send to them.

~~~
hannob
> and there is a lot of technical minutia to not get thrown in the spam folder
> for major providers. In fact, many major providers simply assume mail sent
> from an unfamiliar domain and/or IP is spam by default, and you will have to
> contact them to ask for permission to send to them.

These myths are popular, in my experience they are not true.

~~~
ryan-c
> These myths are popular, in my experience they are not true.

I am speaking from personal experience. I've run my own mail server for about
15 years.

A few months I had to publicly complain on twitter about Microsoft blocking my
email in order to get them to stop putting my email in the spam folder (after
having to move to a new IP). Their support people before I publicly complained
just kept responding with a form letter with advice for commercial senders
sending transactional, newsletter and marketing content.

