IETF Logo Mail Archive

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)

Matthäus Wander <mail@wander.science> Wed, 27 March 2024 12:18 UTC

Return-Path: <mail@wander.science>
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 43F4EC151082 for <dmarc@ietfa.amsl.com>; Wed, 27 Mar 2024 05:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wander.science header.b="F6+UGd/1"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wander.science header.b="xnuZOcy9"
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 y5LOG7K4CsHX for <dmarc@ietfa.amsl.com>; Wed, 27 Mar 2024 05:17:59 -0700 (PDT)
Received: from mail.swznet.de (cathay.swznet.de [IPv6:2a01:4f8:13b:2048::113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBABC151075 for <dmarc@ietf.org>; Wed, 27 Mar 2024 05:17:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wander.science; s=2023-05-rsa; h=Subject:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:MIME-Version:Date:Message-ID:Cc: Sender:Reply-To; bh=BK+NvDFaRPwCvD+TbEI5VSn7dzoy2NYHlrZnUmgtQG8=; b=F6+UGd/1T aidifN1s8Y+od7IzEUz6Fd80Ae/JF5/Sw6rmliQzGs7WMaycnFV3ALkswaeKtZbByISfXq9hXa1oA 9PaGY8trcInK3du6VibyFA8eo5Zo6hwoNriYArU5NYxnfB5owwVphAwdkFjMtKU1xoKXjVJgU14Sz iDRNK+EQCnAks2zW0LAX8OaDo+Qdn6yaZSwwamWgCtSmRnkfvPJl4yhvyO40fnSp3HjyWVsWSHmkk AesiWNKcagwfSdQmpvoPQEtOoV6xTtYzj4gyTTFSagg8gK1pH0D/vHDP2nXfS3ZvuP7reiv7uqrw3 Isb0N9JXs1797wY/TSmhowrsw==;
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wander.science; s=2023-05-ed25519; h=Subject:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:To:MIME-Version:Date:Message-ID:Cc: Sender:Reply-To; bh=BK+NvDFaRPwCvD+TbEI5VSn7dzoy2NYHlrZnUmgtQG8=; b=xnuZOcy9g wxERXlsuCmb6kFj42blTtZ3AvnsNvQqGVyeD8jndNB7a5QslDu6+Lg4xx1KQTqlJQg72oiXGDIlBg ==;
Received: from dynamic-2a01-0c22-b955-0600-dc80-9262-f833-aaaa.c22.pool.telefonica.de ([2a01:c22:b955:600:dc80:9262:f833:aaaa]) by mail.swznet.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <mail@wander.science>) id 1rpSE7-000XpM-QR for dmarc@ietf.org; Wed, 27 Mar 2024 13:17:56 +0100
Message-ID: <c0cd55a6-d755-450b-b176-ad0fdcc211bb@wander.science>
Date: Wed, 27 Mar 2024 13:17:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: dmarc@ietf.org
References: <20240323185339.DA2DD85FCC3A@ary.qy> <97bdc6e7-0170-4101-8b57-2e8e7d8d72c6@tana.it> <3bfe0df7-d5c8-43e9-9e84-ba74cd1bb470@tana.it> <ada8e730-087f-3aa4-3ee3-95e93e6a3255@taugh.com> <2b914f3d-7219-4bea-b072-490cfd7ea672@tana.it> <958c3876-dc44-ae4e-c7f3-cd38ab1dae04@taugh.com> <8b3fea65-cab2-4c6e-9121-487bf4b607a6@tana.it> <41f71ecd-e7ae-4273-aaff-ec5d6f14f641@wander.science> <32b7bb3c-e610-4454-b321-aac8feef41ac@tana.it>
From: Matthäus Wander <mail@wander.science>
Autocrypt: addr=mail@wander.science; keydata= xjMEX32k2xYJKwYBBAHaRw8BAQdAnfSBcaYKuP99+S+Cv7yM2MC5uDVgjDHq72XoUkvDduTN Jk1hdHRow6R1cyBXYW5kZXIgPG1haWxAd2FuZGVyLnNjaWVuY2U+wpYEExYIAD4WIQRN5cud QSNuO9g4P/vwPFqQ1RKslAUCX32k2wIbAwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIX gAAKCRDwPFqQ1RKslBHNAP92aGE3RVTUoVtAOMVyEzC5kpipuYgwEUBGohcKJ6FlkwEAyvGn 2Cqw6T/GOCgcZb3NlOLAAh83v3GOLnbiQxzZgQ3OOARffaTbEgorBgEEAZdVAQUBAQdAMtpC ADRykYF4hU5t/d1ItWsCVcQTrUXARpFGk4s8shADAQgHwn4EGBYIACYWIQRN5cudQSNuO9g4 P/vwPFqQ1RKslAUCX32k2wIbDAUJCWYBgAAKCRDwPFqQ1RKslI9HAP908/+/2MpEH/63y93a 1WB5pcYFy9Do/b0AQjjkfP+ZVQD9EaC+bOBrNgJzHFwhJAHI0l2KD79pMSgXSllPlA0dBQg=
In-Reply-To: <32b7bb3c-e610-4454-b321-aac8feef41ac@tana.it>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 2a01:c22:b955:600:dc80:9262:f833:aaaa
X-SA-Exim-Mail-From: mail@wander.science
X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000)
X-SA-Exim-Scanned: Yes (on mail.swznet.de)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kVRRYv9XmNezWgPlomPnroaf418>
Subject: Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
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: Wed, 27 Mar 2024 12:18:04 -0000

Alessandro Vesely wrote on 2024-03-27 10:00:
> I changed that to /[0-9a-fA-F.:]{2,45}/, to allow "::", and inserted it 
> in dmarc-xml-0.2-short.xsd[*].  At the same time, I added a pattern for 
> "::1.2.3.4" in dmarc-xml-0.2.xsd[†].

I can live with either of these variants.

> I'm not clear what will that schema be used for, if at all.  Personally, 
> the only reason why I'd prefer the long regex is because it might have 
> some value by itself.  The short one is cleaner and more grokkable.  The 
> wrong one has none of those qualities.

I see the following use cases for the schema (sorted from most to least 
important):

1) Provide a precise description to implementers (of both report senders 
and receivers) how a report should look like.

2) Allow report senders to verify the correctness of their implementation.

3) Allow report receivers to perform input validation before ingesting a 
report.

Regards,
Matt

v2.23.0 | Report a Bug | By Email