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.