Re: message encryption with SMTP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Jan 3, 2022 at 7:11 AM Vittorio Bertola <vittorio.bertola=40open-xchange.com@xxxxxxxxxxxxxx> wrote:


> Il 01/01/2022 18:03 Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> ha scritto:
>
> Individuals don't want their MSPs to have their private keys. It's
> possible that MSPs (at least in certain countries) would use the same
> mechanism as enterprises to force disclosure of private keys.   In
> theory individuals can have their own DNS names and set up their own
> SMTP servers.  (making this manageable by ordinary people at scale is
> still an unsolved problem but might be solvable)   But oppressive states
> would probably try to thwart that.

Actually, today the biggest obstacle for those users (like me) that insist on running their own 1-domain, 1-user SMTP server is that the "intelligent" antispam filters of Gmail and the likes will very frequently treat you as a spammer by default, and taint or even reject your messages. The message flows are simply too small for data-based heuristics to work well.

In general, any hurdle against the deployment of personal or small-scale email servers - apart from the usual consolidation issues - will hit exactly those users who care about their privacy up to the point of running their own server. This is something we should pay attention to.

The big benefit of moving to a separate infrastructure in which every message is authenticated and subject to access control with a default deny posture is we can leave the SMTP anti-spam heuristics behind.

Heuristics are the worst sin any protocol designer can commit. The original sin in SMTP was the chap who decided to wrap the lines of email in the server rather than the email client. If you run Windows in compatibility mode, files do not register as being deleted for some time after they are erased because that behavior was necessary to make some program to work in the DOS era.

When people ask me 'why not use SMTP', they start with the assumption that this is should be the default. That is not the way I work. After 40 years, it is pretty clear that every avenue for incremental improvement of SMTP has been exhausted. But the thing that really sealed the fate of SMTP was the anti-spam heuristics. Once you have resort to heuristics, you cease having a proper standard. It was a necessary decision at the time but it came at a cost.

 
> I think there's room to add mail encryption to SMTP.  The protocol
> extensions can be worked out, and major MSPs would probably find them
> attractive to their customers.   I believe that doing so would raise the
> bar for some kinds of attacks and malicious behavior.   But there's no
> way to please everybody, and maybe no way to really provide the privacy
> that many of us would like to provide.

As a webmail provider to several big ISPs, we offer an OpenPGP-based UI extension that allows users to encrypt/decrypt messages, managing keys etc. Not all of our customers want it, and in general, the feedback is that the end-user demand for e2e-encrypted email is very low. In the past years we put quite some educational effort in promoting STARTTLS and proper encryption configuration (e.g., disable insecure ciphersuites) and that seems to be the most of encryption that currently the mass market demands.

The DNC attack changed the course of the 2016 US presidential election. People should have learned data at rest security is the issue and email at rest the most critical issue.

They won't of course which is why I am not proposing an email replacement. I am proposing an end-to-end messaging infrastructure on top of which secure workflow systems can be built. 

One of the first applications I have built on that infrastructure configures email clients such as Outlook and Thunderbird for use with SMTP/IMAP/POP and provisions OpenPGP and S/MIME credentials.

It also handles the contact exchange so that we can exchange our OpenPGP and S/MIME credentials through multiple modalities ranging from bumping phones, QR codes, CA brokered, message loopback, etc. 

But this is like building a monorail to every house in the city and using it to deliver hay for the horses pulling people's buggies. Sure it works and some people prefer the horse and buggy solution (mostly the folk don't have to deal with the manure'. But if you build it, sooner or later, the people are going to be riding the monorail.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux