Re: Service outages planned for April 25

Carsten Bormann <cabo@tzi.org> Thu, 28 April 2022 11:04 UTC

Return-Path: <cabo@tzi.org>
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 2E41AC14F741 for <ietf@ietfa.amsl.com>; Thu, 28 Apr 2022 04:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Mi0tf-E0XG4b for <ietf@ietfa.amsl.com>; Thu, 28 Apr 2022 04:04:46 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4BC41C14F74A for <ietf@ietf.org>; Thu, 28 Apr 2022 04:04:45 -0700 (PDT)
Received: from smtpclient.apple (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Kpt6z0BdZzDCdx; Thu, 28 Apr 2022 13:04:43 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Subject: Re: Service outages planned for April 25
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <664edff3-3690-995f-1c1e-ce3e6c5c1eae@network-heretics.com>
Date: Thu, 28 Apr 2022 13:04:42 +0200
Cc: ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <44D37C5A-74E0-4C2E-AB5D-E0AA2F846331@tzi.org>
References: <dcc27c29-51f8-c2a4-8ce4-ee1a3c6cb017@nostrum.com> <66aebf8b-2835-d572-ad00-eb2df514a157@nostrum.com> <626A610B.9050508@btconnect.com> <A449287A-CDA4-4173-8691-7049488FD130@ietf.org> <664edff3-3690-995f-1c1e-ce3e6c5c1eae@network-heretics.com>
To: Keith Moore <moore@network-heretics.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7Yh4n5uypWDYdZ-_ojoY3YiZQ4Q>
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: Thu, 28 Apr 2022 11:04:48 -0000

On 28. Apr 2022, at 12:51, Keith Moore <moore@network-heretics.com> wrote:
> 
> I can't help but notice that the fact that it was necessary at all is a sign that email interoperates poorly in practice,

We knew that :-)

> and a sign that IETF has failed to maintain the email protocols to keep them interoperable.

FTFY:

and a sign that IETF has failed to create an economic and regulatory environment for email that doesn’t make it viable for a large player to optimize their own convenience at the detriment of interoperability with others.

But wait, the IETF is not in the business of creating economic and regulatory environments.

The question (that should please not be answered here on the ietf@ mailing list) is:
What would have been the technical changes that might have made it less viable for a (single) large player to base spam mitigation on a locally learned concept of address reputation?

BTW, I hear evidence that that player has now learned the new IETF IP addresses.

Grüße, Carsten