Re: [ietf-smtp] Email explained from first principles

Richard Clayton <richard@highwayman.com> Fri, 28 May 2021 08:28 UTC

Return-Path: <richard@highwayman.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14213A2026 for <ietf-smtp@ietfa.amsl.com>; Fri, 28 May 2021 01:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2F0T3Mhsy4z for <ietf-smtp@ietfa.amsl.com>; Fri, 28 May 2021 01:28:19 -0700 (PDT)
Received: from mail.highwayman.com (mail.highwayman.com [82.69.6.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4913A2023 for <ietf-smtp@ietf.org>; Fri, 28 May 2021 01:28:18 -0700 (PDT)
Received: from localhost ([127.0.0.1]:29733 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.94.2) (envelope-from <richard@highwayman.com>) id 1lmXqq-0003LG-K2 for ietf-smtp@ietf.org; Fri, 28 May 2021 08:28:16 +0000
Message-ID: <M8PwJUBhlKsgFAoM@highwayman.com>
Date: Fri, 28 May 2021 09:27:13 +0100
To: IETF SMTP Mailing List <ietf-smtp@ietf.org>
From: Richard Clayton <richard@highwayman.com>
References: <20210524140315.991E3890E35@ary.qy> <6E17FD4E-C3D7-4703-8E5C-B0364D011418@ef1p.com>
In-Reply-To: <6E17FD4E-C3D7-4703-8E5C-B0364D011418@ef1p.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Mailer: Turnpike Integrated Version 5.03 M <y+2$+vR+77vZxPKLUrf+da3KSn>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/_hnErfmk95RM3U-RcEZTFVC-aXM>
Subject: Re: [ietf-smtp] Email explained from first principles
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 08:28:24 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <6E17FD4E-C3D7-4703-8E5C-B0364D011418@ef1p.com>, Kaspar Etter
<kaspar=40ef1p.com@dmarc.ietf.org> writes

>Other efforts to curb phishing, such as 
>BIMI, 

You will not find any claim on the BIMI website that says that it will
curb phishing (and, in my view, with good reason)

>also require domain authentication. (BIMI also addresses homograph attacks 
>with verified mark certificates.)

It has always been unclear how similar looking trademarks (indeed
identical ones, since trademarks are only unique within a single
economic sector within a single jurisdiction) will be handled by BIMI

... but while only a small number of brands, mainly from one country,
are the only users of the mechanism this is not an issue that they have
to resolve so far

>One of the nice things about DMARC is that it makes domain authentication opt-in 
>for those who want this (even if the reason for this feature is mainly backward 
>compatibility). I’m honestly surprised to see that almost no one here uses DMARC 
>with a policy of reject or quarantine, but I don’t mind this because it’s your 
>call.

you'd be even more surprised if you started to investigate how few
mailbox providers honoured a reject request

>On a different note, the problem with malicious display names is much worse than 
>many people are aware: Most of the mail clients which display only the display 
>name do so even if the display name is itself an email address. Emails from 
>`"bob@example.com" <alice@example.org>` are displayed identically to emails from 
>`bob@example.com <mailto:bob@example.com>`. See https://explained-from-first-
>principles.com/email/#malicious-display-names <https://explained-from-first-
>principles.com/email/#malicious-display-names> for more context.________________

I think most people who have thought about how to tackle the issue of
misleading display names are well aware of this relatively simple issue,
it's all the other complexity that has hindered attempts to tackle the
issue...

... and of course the real issue with phishing is that systems are
(still being) built with the assumption that end users will be able to
reliably identify legitimate communications and disregard the messages
from the bad guys. Since that will never be true, any system which
relies on the assumption will fail.  viz: trying to help the user make
better decisions is merely a sticking plaster

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBYLCpYd2nQQHFxEViEQJXJACg0XN1HvJQvWSc34wXqUYiDq09vDUAoNXS
ALFERQqFgOmlZzeNUJh3cfas
=0PT6
-----END PGP SIGNATURE-----