Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 13 May 2022 20:13 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BA8C14F74B for <ietf@ietfa.amsl.com>; Fri, 13 May 2022 13:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level:
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwadilJwtqHF for <ietf@ietfa.amsl.com>; Fri, 13 May 2022 13:13:06 -0700 (PDT)
Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708A0C14F746 for <ietf@ietf.org>; Fri, 13 May 2022 13:13:06 -0700 (PDT)
Received: by mail-yb1-f171.google.com with SMTP id v59so17104601ybi.12 for <ietf@ietf.org>; Fri, 13 May 2022 13:13:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OiiSyJ3bBrb1J87d/Nlr3NsVX1j/7h+f8h9M5fZw/3g=; b=z9P2dttFLAYh2FJI0lC8+uIgiiZRDZLyoatd6OXJdhNkLeO1jtXtVgJTAStTyuKyfy W0st/JJUXLxbUVOXHAed1dQ1TtJ3b85e9OdxEi22Ij8Ahte2fNFHVuZbYtVY0fBTSjK8 fvbOc1CMdgrhcf3zEZMudDY7eK90/TpBM0ZHfyW5KPs6i394acC1rH2MO86p5lHb0CXY BkSZB/ZHM1yl0IHdXfkVVLPmkaEkpJMmFJWH497JN4nRchrp50E8ujqLejBVn9MGIagv D3egNRU6P44XoAGjSmoioJqaBvL9btMh/0BgWN3QBqWQ71rvLWqpEvFqfOQiYcRn44TE TZMQ==
X-Gm-Message-State: AOAM532Np3nN6PEpsuXsSXZ1FBPgcg0lcMVjB8xRRbtXDDWkSWpUs3XI sWbMffadC3uFPx6P1aeLqhOAi/2qfVsHkVZtf8acJzykflQ=
X-Google-Smtp-Source: ABdhPJydaHL20y8zqcoLq8fqnVOWXDEQy5RLeEg8tgF8+GLWYWTfE9Rwv0eKZutiSqdAceHCIU2Sdbivi4dirQ+mlqo=
X-Received: by 2002:a25:d987:0:b0:64b:6f4e:8558 with SMTP id q129-20020a25d987000000b0064b6f4e8558mr6632535ybg.133.1652472785616; Fri, 13 May 2022 13:13:05 -0700 (PDT)
MIME-Version: 1.0
References: <dcc27c29-51f8-c2a4-8ce4-ee1a3c6cb017@nostrum.com> <AAE3C51B-0150-483C-8244-3D60BC31B19A@tzi.org> <2c5df733-0f86-d319-b886-81882328caa9@network-heretics.com> <1870005490.14504.1651151102962@appsuite-gw1.open-xchange.com> <t4f3j1$1mpc$1@gal.iecc.com> <626060406.28268.1651487745123@appsuite-gw1.open-xchange.com> <2480fd36-c16a-6d98-ddac-15d02259ffbe@taugh.com> <837df6ce-a771-ff2f-515b-1021cc242c23@network-heretics.com> <0abc737b-839a-ba8e-88c2-64b7f069a9c7@huitema.net>
In-Reply-To: <0abc737b-839a-ba8e-88c2-64b7f069a9c7@huitema.net>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 13 May 2022 16:12:53 -0400
Message-ID: <CAMm+LwhD8wHJ284z91X5XP-8f+9=Dx1Kd50=8-Pd3SX==W6ivw@mail.gmail.com>
Subject: Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)
To: Christian Huitema <huitema@huitema.net>
Cc: Keith Moore <moore@network-heretics.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000063440005deea4d94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/bgWN5CQIIkqh9y4vPPhV5GpnCcc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2022 20:13:07 -0000

Since y'all are claiming this problem is impossible, I want the glittering
prizes if my proposal turns out to work.

I have some running code but what we are talking about now is in the
architecture but not the code. The code allows Alice to send an
authenticated message to Bob. What the code does not currently have is the
Authorization Policy layer which I will describe here.

The starting point for this design was 'what if I was designing a messaging
system for Madonna'. I want her to be able to put her contact address on
her business card without getting her personal or business folders being
deluged by fan mail. If I can solve that problem, I am pretty sure that the
spam problem is a subset. So unlike with telephone numbers or email
addresses, I assume that the contact address is public. Madonna will
put @madonna on her business card, I will put @phb on mine. We both end up
with a functioning messaging system.


So I want to control who can communicate with me. I have
multiple communications modalities that I accept messages through

* Contact requests
* Asynchronous messages
* 2FA /Confirmation requests
* Synchronous text, voice, video
* Payment requests
* Workflow items.

Every Mesh message is authenticated without exception, so its all about the
authorization policy.

So the first thing the Mesh does is to allow me to set different
authorization policies for each. So let us imagine that Alice wants to call
me at 2am in the morning. Not happening, she doesn't have that permission.
My kids however, get to call me for a ride home no matter what time of day
or night.

People can and will abuse any messaging modality but for the point of view
of spam control, I would be MUCH MUCH MUCH MUCH MUCH MUCH MUCH MUCH MUCH
MUCH better off is the only folder I was receiving communications from
unknown parties was my contact requests folder.


So how would I set the authorization policy for my contact requests? I am
going to make use of a number of strategies and adapt according to
circumstances. Initially, I will allow anyone to send me a contact request.
After a while, I might set a policy that in order to get priority in my
contact requests, you must have an introduction. This may be from someone I
know and have authorized to give introductions, an organization or a
conference.

So for example, I think I would be pretty safe accepting contact requests
from:

* Anyone who is an Alumni of Southampton, Oxford or MIT
* Anyone who has attended an RSA Conference, IETF, OASIS or W3C meeting
* Anyone with an introduction from someone I have authorized to give
introductions
* Anyone who is an accredited expert witness search agent
* Anyone whose validated email address matches one of my SMTP contacts

That is going to cover the vast majority of my legitimate contact requests.


Now the secret of keeping Disneyworld clean is that the park is already
clean. The big problem with spam is that once it gets to a certain point,
all you can do is to mitigate. If you keep the park clean, there is not a
huge incentive to try to break the system because it really isn't
profitable enough to be worthwhile.

Madonna will have a considerably larger number of people trying to get in
contact but just doesn't have the time. So her policies will likely look
very similar but with people in the recording, movie, etc industry getting
the pre-authorization. So if Chris Helmsworth invites her to an Avengers
party, that goes straight into her personal inbox. While a message from a
fan sent to the same address goes to one of her PAs and get the standard
fan response.

This is exactly how the President's snail mail was being processed back in
the 90s when we were doing the Whitehouse email project. POTUS gets two
containers full of letter post every single day. Every letter is opened and
read by a team of volunteers. These are digested down to a daily summary
that is one of the first things that Clinton and Obama would read every day.


So how do people get the introductions etc? Well historically, that was the
primary function of professional bodies, to introduce members to clients
and to each other.

How hard is this to break? That will depend on implementation. But a system
doesn't have to be perfect to provide real value. There is a huge
difference between today's situation where over 95% of all the emails and
50% of the telephone calls I receive are spam and one where less than 5% is
spam and that only in the contacts folder.