Re: [ietf-smtp] Email explained from first principles
John C Klensin <john-ietf@jck.com> Fri, 28 May 2021 14:27 UTC
Return-Path: <john-ietf@jck.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 4C9103A2AF3; Fri, 28 May 2021 07:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 EzvniUjEyz4o; Fri, 28 May 2021 07:27:19 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D765E3A2AE7; Fri, 28 May 2021 07:27:12 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lmdSB-000Luf-4j; Fri, 28 May 2021 10:27:11 -0400
Date: Fri, 28 May 2021 10:27:05 -0400
From: John C Klensin <john-ietf@jck.com>
To: Kaspar Etter <kaspar=40ef1p.com@dmarc.ietf.org>, John R Levine <johnl@taugh.com>
cc: IETF SMTP Mailing List <ietf-smtp@ietf.org>
Message-ID: <F43E00C7D57DBDB88E527909@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/jEgjRy2mcrfyZE3C1Ee2FkS9Vv8>
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 14:27:32 -0000
--On Thursday, May 27, 2021 19:15 +0200 Kaspar Etter <kaspar=40ef1p.com@dmarc.ietf.org> wrote: > On 27 May 2021, at 18:23, John R Levine <johnl@taugh.com> > wrote: >> We've spent a decade with people insisting that the entire >> e-mail world has to change the way it works to conform to the >> lastest FUSSP. > > Why is domain authentication framed as a spam prevention > technique? Any messaging service which is popular, open, and > free will have spam. Spam is a problem of quantity: You just > have to bring down the amount of unsolicited messages to a > bearable level, be it with domain or IP reputation, > challenge-response mechanisms, or proof of work. Phishing, on > the other hand, is a problem of quality: A single successful > attack can do immense harm. It's not just large > organizations which are being impersonated. A popular scam is > to impersonate the victim themselves, claiming that their > account has been compromised and blackmailing them into paying > a ransom. > > Just because some people will always fall for scams doesn't > mean that we shouldn't try to reduce the number of victims. > Otherwise, cars wouldn't need safety measures because some > people will always die in car accidents. Priming plays a huge > role in human psychology and there's a lot that mail clients > could do in this regard: Separate messages from unknown > senders, don't display the display name of unknown senders, > warn users when they click on links from unknown senders, warn > users if a previously authenticated sender could not be > authenticated, etc. > >> They understand that DMARC's limitations cause a lot of >> gratuitous pain for their users who've been using mailing >> lists for a long time. > > I fully understand this pain and respect the motivation behind > ARC, but you cannot have (strict) domain authentication and > message rewriting. I want the former and don't care about > the latter. Maybe the solution will be that people use two > different addresses: One with domain authentication enabled > for direct conversations and one without domain authentication > for mailing lists. Kaspar, This is rapidly evolving into what is often known here as a religious debate. Such debates are rarely useful: one group of people start with fundamental and strongly held principles about what email is about and what is therefore most important to optimize, others have a different set, and then they often go off and argue about things that are really just corollaries of the assumed principles. That is also the disadvantage of trying to construct an argument and explanation "from first principles", especially if the hypothesized princinples are not explicit: if others disagree with you about what those those principles are, it may not be useful to have conversations about the derived explanation and details. Let me give an example using part of the above thread. I am, personally, not a big fan of domain authentication. My problems are tied, not to any particular detail but to two operational/ political problems. The first is that any such system is inherently dependent on the integrity, responsibility, and accountability of domain name registrars and domain operators. I guess the most charitable thing I can say about that is that some are better than others and that their business models and incentives may not be the same as those of email providers, much less those of the recipient email user. Even some email providers are problematic: absent legal action, when was the last time you heard of a major email provider closing an account and deleting a mailbox because it was used as the reply address in some phishing, extortion, or other fraudulent scheme? Or how often do you see a major provider require strong authentication to establish a mailbox and then having terms and conditions indicating that any fraudulent or illegal use of the mailbox would result in termination of the account and handing the user over to law enforcement? Is authentication that a mailbox exists in a domain and that someone is allowed to send mail using/ through the domain better than nothing? Yes, clearly. How much better? Well, it cuts down on the number of really stupid evildoers. Some of us worry more about the smart ones, even the smart ones who have concluded that they will be more successful making the sort of deliberate "mistakes" that confine their likely audiences and potential victims to really stupid users, but that is probably another religious issue. The political side of the problem is that, as long as someone can behave in an evil or criminal way but do it in a way that allows escaping any chance of punishment (such as by carrying out the bad behavior from a country that does not consider the behavior criminal, as least if it is not applied to their own citizens), then, under the best of circumstances, trying to stop the behavior is an arms race and a losing one. And, if we can figure out ways to stop a large percentage of the evil traffic, it actually reduces the incentives to deal with either those underlying political /legal issues or with the education and technology that appear to be prerequisite to making PKI-based authentication work at an individual level for most of the email users in the world. And, that, of course, leads to another political/social problem: to the degree to which solutions depend on high-quality user authentication, that level of authentication may be incompatible with highly valued ideas of privacy and potential anonymity. Finally, as John Levine and others have more or less pointed out, getting some of these problems solved may require either a cure for human stupidity and carelessness or training, certification, and licensing of Internet users. I have no idea which of those is less likely. best, john p.s. some of us already use different addresses for individual/direct communications and for mailing lists. In practice, it does not work well for the purpose you describe with or without domain authentication because message threads, and the addresses used with them, transition back and forth between the two realms.
- [ietf-smtp] Email explained from first principles Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… Bron Gondwana
- Re: [ietf-smtp] Email explained from first princi… Alessandro Vesely
- Re: [ietf-smtp] Email explained from first princi… Viktor Dukhovni
- Re: [ietf-smtp] Email explained from first princi… Viktor Dukhovni
- Re: [ietf-smtp] Email explained from first princi… Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… Peter J. Holzer
- Re: [ietf-smtp] Email explained from first princi… John Levine
- Re: [ietf-smtp] Email explained from first princi… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John Levine
- Re: [ietf-smtp] Email explained from first princi… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Matthias Leisi
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Nathaniel Borenstein
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John C Klensin
- Re: [ietf-smtp] Email explained from first princi… Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] Email explained from first princi… Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] Email explained from first princi… Richard Clayton
- Re: [ietf-smtp] Email explained from first princi… Alessandro Vesely
- Re: [ietf-smtp] Email explained from first princi… John C Klensin
- Re: [ietf-smtp] the point of domain authentication John R Levine
- Re: [ietf-smtp] mailing lists are complicated, wa… John Levine
- Re: [ietf-smtp] the point of domain authentication Sam Varshavchik
- Re: [ietf-smtp] the point of domain authentication John Levine
- Re: [ietf-smtp] mailing lists are complicated, wa… Alessandro Vesely
- Re: [ietf-smtp] mailing lists are complicated, wa… John R Levine
- Re: [ietf-smtp] mailing lists are complicated, wa… Dave Crocker
- Re: [ietf-smtp] Email explained from first princi… Richard Clayton
- Re: [ietf-smtp] mailing lists are complicated, wa… Alessandro Vesely