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

Tom Pusateri <> Fri, 02 June 2023 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB5EDC14CE47; Fri, 2 Jun 2023 07:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R1BCrKN_81Bt; Fri, 2 Jun 2023 07:39:00 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 0866AC14CE27; Fri, 2 Jun 2023 07:38:59 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 16CB8C465; Fri, 2 Jun 2023 10:38:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201907; t=1685716738; bh=Ra4gMu1xD/35e06rS78vNjtwWvzcJYUQQYAL1fSXJa8=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=G7peqO4a96FZigvQK8X4Nml2rdWLZbooCk8Gi8ppyxwvtgjSh2nbhBCDlFLpLMnHb 8hUlQ4l7bfO+AvH+WZM2u4zX4eMHoQ3C+2nfPIgZUD2LNMwGOWT0eoEhhrmbSXgT4L hNHptKcV5d8U9tAQGKPuiyM502fZybcRW/PI5lj1dPIrbSYcsqTyX7k/MzuONclwRz EFF6QYE2Bv2erLlluSo1j5lPW9KYOqBOPWmhWzwEkny9P3gWyxp4B53argjhkl/Rdf a8JXGYo07dA/hY8HzYh5ctcy0KPT6WY++KLyFPvUzJVrZkXGNwnBOYsh5rXgolirE2 TTnlW4cX12G2w==
Content-Type: multipart/alternative; boundary="Apple-Mail-F0874E4F-AFCD-4AAB-9987-26A8D84ED2BC"
Content-Transfer-Encoding: 7bit
From: Tom Pusateri <>
Mime-Version: 1.0 (1.0)
Subject: Re: [Tools-discuss] Weird messages from IETF/Google Mailservers (WG: PALS WG Adoption poll draft-schmutzer-pals-ple)
Date: Fri, 02 Jun 2023 10:38:46 -0400
Message-Id: <>
References: <>
Cc: Barry Leiba <>,,
In-Reply-To: <>
To: Toerless Eckert <>
X-Mailer: iPad Mail (20F66)
Archived-At: <>
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Working Group Chairs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jun 2023 14:39:04 -0000

If this upcoming book is as good as his other books, you will find Michael W. Lucas’ new book “How to run your own mail server” very helpful when it is released:

While you may not run your own mail server, the techniques and best practices will be explained.


> On Jun 1, 2023, at 7:05 PM, Toerless Eckert <> wrote:
> 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:
>> ...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 (TXT record
>> in, and here it is:
>>   v=DMARC1;p=none;;;
>> 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 <> 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
> -- 
> ---
> ___________________________________________________________
> Tools-discuss mailing list - -