Re: [ietf-smtp] epostage is still a bad idea, the inedible parts of IETF dogfood consumption - SMTP version

[Brandon Long <blong=40google.com@xxxxxxxxxxxxxx>]

On Wed, Dec 18, 2019 at 11:12 AM Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:

If we knew how to deploy such a radical change as sender pays, we would surely also know how to do the much easier task of replacing SMTP with a protocol that is secure by default.

* Every message is signed by the sending client.

* Every message is signed by the originating mail service.

* Every mail receiving service performs access control on inbound messages

* Every mail client performs access control on messages

Messaging abuse isn't entirely absent on Facebook, Skype, Signal, etc. but it is virtually non-existent compared to telephone and email. We are rapidly reaching the point where a large number of customers are going to start unplugging from POTS and only use it for voice mail because the level of abuse is utterly insane.

Subjecting every message to access control is pretty straightforward when you can start with the principle that every message is authenticated by the sender. Defining a set of access control rules that work for me is pretty straightforward. 

1) I will accept a contact request of 200 characters or less from anyone 

2) I will accept requests from anyone in my contact book that are compatible with the authorizations specified there (e.g. Alice can send me mail or voice, Bob only voice, Carol can send me code, etc).

3) I will accept messages from anyone who has attended an IETF meeting or is a member of an an affinity group I am a member of (school, university, etc. etc.)

4) Reject everything else

Trying to shoehorn this into the legacy SMTP environment is tough because the default is insecure. But there are plenty of closed environments that don't use SMTP which could switch to another messaging protocol.

While I was writing this, I was interrupted by the Nest telling me something I didn't need to know. There is also a 'secure' messaging center on the Nest site and I have the same for each of my banks, brokers, etc. Wouldn't it be nice if all of those could send me messages using a protocol they know is secure and meets their HIPPA, GDPR, MMQF, etc. requirements?

The challenge with the secure messaging systems is only partially due to transit concerns, they also want to be in the loop for the ACL to view the message and control the lifecycle of the message as well.  

Brandon