Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

Tero Kivinen <kivinen@iki.fi> Mon, 01 April 2024 09:20 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF257C14F616 for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 02:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.163
X-Spam-Level:
X-Spam-Status: No, score=-4.163 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, NICE_REPLY_A=-2.064, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 b_UeA3EJMXM4 for <dmarc@ietfa.amsl.com>; Mon, 1 Apr 2024 02:20:12 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 0EB72C14F601 for <dmarc@ietf.org>; Mon, 1 Apr 2024 02:20:10 -0700 (PDT)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 4V7QTL6NYWzyRk; Mon, 1 Apr 2024 12:20:06 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1711963207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S9TSzdcc8Mc53tYEhPAOdYQOupVCG0nHDQcooULjW/c=; b=cD1/C4M6f82jCN+dt5uXDT3KB+LVIbfLCgztlkoAJ43GPHceaq1S/GHwpFWS7WbZlYiAzs +BVqru5Zi1D94MjgMkWo5E6ZAu28e1a4wkXxGv2jo1wABISA6NxdnNqTysByHlMiPOO6do ANRFvKq9rTWshc+2rZnQ71BLSiTJI0A=
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1711963207; a=rsa-sha256; cv=none; b=UDda3f3lq4HiTcYbujL/FErc5CDd2r/QzASuN2c08SF4jYGkdxzC+KM5P9zI89+hH+ebzN JDiFHLyiUzEw9pJQZMs9HGgM3oYJJCYLpR2BVv9BaGwEyaFOwWr480f3PhXek+rjfTUT9f ZlOJ54VbRrlqwBHRKb4ek5CMT3qSTKA=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1711963207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S9TSzdcc8Mc53tYEhPAOdYQOupVCG0nHDQcooULjW/c=; b=ZUDhAHmzfWdhef3MVk+lxdTMIiKYeZ0dqHi6i4v9480GdJjm9tclQQja9hsBaO5ftvnFIG JWrQgr36ks4cg6NpFQShFVAl2M6MoftW8PP7oanVjYsEFEoBy+pFa05Z817wmN6mkFylfn 0AxzR6JHaH6/333yNKSOyUuBqIulm0k=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 2DBF425C130F; Mon, 1 Apr 2024 12:20:06 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <26122.31814.114326.395968@fireball.acr.fi>
Date: Mon, 01 Apr 2024 12:20:06 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Alessandro Vesely <vesely@tana.it>
Cc: dmarc@ietf.org
In-Reply-To: <d4405d75-f22e-4cdc-92d9-71a3fc258c13@tana.it>
References: <CAOZAAfPwJHKGyLjTkdGDqkMeK4RQX4Fj0rw-Upn0cLZ+cE74aA@mail.gmail.com> <2cdd13ec-9d7f-4732-91ea-9c8983d7a28c@tana.it> <CAH48ZfzaNR2A6zUWVeeoay+UHLHTzja9f5RGfAt5htXd21C0KQ@mail.gmail.com> <d4405d75-f22e-4cdc-92d9-71a3fc258c13@tana.it>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 11 min
X-Total-Time: 12 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/oWVuic4KhhEQwS2PuSu1UnPvqkQ>
Subject: Re: [dmarc-ietf] WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2024 09:20:15 -0000

Alessandro Vesely writes:
> On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote:
> > On SPF, our document should say simply,
> > " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF result, 
> > prior to receiving the Data section and checking for aligned and verifiable 
> > signatures."
> 
> 
> Nonsense.  Rejecting at RCPT TO is much quicker than waiting for the whole 
> message.  People who publish -all know what they do.
>
> I also reject based on RBLs and private IP lists; does that affect DMARC 
> compliance?

Yes, either one of those practices are not using DMARC to validate the
messages.

Of course you are allowed to do whatever extra checks you want for the
incoming emails, you can even reject ever email coming in from
ip-address is even number, but that is not DMARC.

To implement DMARC you have to follow the rules set in the DMARC.

I.e. if you are implementing DMARC you MUST follow the rules set in
section 5.7.2 and the step 3 requires you to do DKIM signature
verifications checks, which you can't do if you reject email before
the you even see the body that contains DKIM signatures. Actually you
can't do steps 1 and 2 of the 5.7.2 if you reject email before body as
you do not know RFC5322.From domain, so how can you claim to be
implementing DMARC if you do not even load DMARC policy record.

So you can do whatever extra checks you want, but those are not part
of DMARC, and should not be considered here. If you actually implement
DMARC, you already MUST NOT reject a message based on the SPF results
prior to receiving data section, as that is already mandated by the
section 5.7.2 dmarc, so saying that again in the draft is not adding
any new requirements, it is simply restating the same requirement in
different words for implementors just in case they did not properly
understand the section 5.7.2.
-- 
kivinen@iki.fi