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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Dec 19, 2019 at 3:52 PM Brandon Long <[e-mail]> wrote:

>
>
> On Wed, Dec 18, 2019 at 11:12 AM Phillip Hallam-Baker <
> [e-mail]> 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.
>

Oh don't tempt me, I would love to be able to add Micali Fair Contracts to
my code...