Re: Weird messages from IETF/Google Mailservers (WG: PALS WG Adoption poll draft-schmutzer-pals-ple)

Toerless Eckert <tte@cs.fau.de> Thu, 01 June 2023 23:05 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CCEC1519AA; Thu, 1 Jun 2023 16:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.647
X-Spam-Level:
X-Spam-Status: No, score=-6.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 EblgUCeE6xJd; Thu, 1 Jun 2023 16:05:20 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (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 03BF8C1516E9; Thu, 1 Jun 2023 16:05:12 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4QXMD20YTCznkVR; Fri, 2 Jun 2023 01:05:06 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4QXMD1716Yzkw3C; Fri, 2 Jun 2023 01:05:05 +0200 (CEST)
Date: Fri, 02 Jun 2023 01:05:05 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Barry Leiba <barryleiba@computer.org>
Cc: Jim Fenton <fenton@bluepopcorn.net>, wgchairs@ietf.org, tools-discuss@ietf.org
Subject: Re: Weird messages from IETF/Google Mailservers (WG: PALS WG Adoption poll draft-schmutzer-pals-ple)
Message-ID: <ZHkkIR8h0On3168p@faui48e.informatik.uni-erlangen.de>
References: <BEZP281MB2008B40D838DDC78B76B4DFA9849A@BEZP281MB2008.DEUP281.PROD.OUTLOOK.COM> <ZHinT9Y4Ffn0tcwD@faui48e.informatik.uni-erlangen.de> <9898F7C3-7139-474B-B9A6-22A6B09E7D52@bluepopcorn.net> <CALaySJLGK92TtzrpKwV3v-XcWNxLUY3wqObv=Qvkaujc=aXHcQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALaySJLGK92TtzrpKwV3v-XcWNxLUY3wqObv=Qvkaujc=aXHcQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/AMIZb4wNXQac25Q35LhRn5X8WJM>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jun 2023 23:05:24 -0000

Thanks, Barry

As i said i did not have the time to read up on all that mail "security".
Its nice to hear that DMARC is not standard, but i wouldn't even want to
voice a strong opinion wheter or not it should become one without understanding
this all better. Alas, as said: reading all the RFCs around it is a lot less
efficient than some more operator centric representation, that i can't find
(operational issues).

In any case, it would be nice if there would be a BCP in due time about the
actual operational practices including warnings about the severe implications
of what you call "overstepping" below.


Cheers
    toerless


On Thu, Jun 01, 2023 at 10:46:51AM -0400, Barry Leiba wrote:
> But we *are* finishing work to standardize DMARC:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
> ...and there is a huge controversy in the working group about what
> normative things to say about this, and whether we should say anything
> normative at all.
> 
> But this is something different; gmail appears to be seriously
> overstepping.  I checked the DMARC record for telekom.de (TXT record
> in _dmarc.telekom.de), and here it is:
>    v=DMARC1;p=none;rua=mailto:dmarc@telekom.de;ruf=mailto:dmarc@telekom.de;
> 
> They are publishing a "p=none" policy, which should *not* trigger a
> rejection because of failure to authenticate.  Yet gmail is rejecting
> it anyway (as if the policy were p=reject).  I will ask my gmail
> contact about this.
> 
> Barry (chair of the DMARC working group)
> 
> On Thu, Jun 1, 2023 at 10:38 AM Jim Fenton <fenton@bluepopcorn.net> wrote:
> >
> > On 1 Jun 2023, at 7:12, Toerless Eckert wrote:
> >
> > > Please complain with the ART email folks. It is the IETF that standardized all those
> > > email "security" mechanisms such DMARC that google is now using to effectively make
> > > email unusable for many people (and this is primarily what i heard from outside the IETF).
> >
> > IETF did not standardize DMARC: RFC 7489 is an informational specification published via the independent submission track.
> >
> > Unfortunately many people and organizations, including some that are mandating the deployment of DMARC and publication of “reject” policies, so not understand the difference between informational and standards-track.
> >
> > -Jim
> >

-- 
---
tte@cs.fau.de