Re: [dmarc-ietf] Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization

Дилян Палаузов <> Fri, 10 May 2019 11:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63EB612004E for <>; Fri, 10 May 2019 04:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hyq6NeE9ur6r for <>; Fri, 10 May 2019 04:06:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67960120026 for <>; Fri, 10 May 2019 04:06:41 -0700 (PDT)
Authentication-Results:; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1557486398;; r=y; bh=fdy/O1BtCcJm1PpnUJ9nxq5cdrDEMdSOhFTtoOSWMBc=; h=Subject:From:To:Date:In-Reply-To:References; b=EHO6bYQSYBRQIBPQrq5KWZJe5cH8jvEok42GjX0JMxqWZ9Ajd1JGtGIWGVGAM2RUk dqD0irIAGmHo5M9MIsPapProDCs/WVDAoBfNYnyx3zBi80qY5zIN4p33OGcdXrXWvN RHB6jwc2lKYWNLuNb0p6NmRkadmaBYSmMT6ChaNydkVGR1aP3Qm6HQ2rih/n347anb Dohncv/dPp1tbiOvXpp4W/bLFS8A6RUmrg0JcXcJLVyvm+1ElfmShQ9Up9MVhR+mcp P276bP7w+0ifaS2gtn1TWbL+FHcXVNlc5h31QNWFIxWMuSxU+j6iquCJTrC6oFc2j+ JcPQgTs9rMPtE/psRIwZi/7g4nC8q5lNjUr2YGorCloyEmgW2V3NVrIJUTV0UpA34J rtODBXgmMIsFsjWIlQVILnXYmoT8UPXOx6gC3Qh1nl2Soq0hp3t9aVVyysI9wuKTBc yMUOtYErIEg5CcYbDHH9tiBXMVINnVIU1IEIOh+iqRy25CyA9oAWd9HGhfPdUG9ej3 76z9PS6TjLExH5b3kA7TAto3Ryis/ZS2G6SwP5Z6Wu8n93/u0l2mg9yUcrQnk8iQWP 0zgTereiZjeQvNOofshxcUvdYbLghHqfDUbm87+JtjpADjuT9HYLbGqkZP4HiM86dU x/vCguqBwM16nsI31wqt9peU=
Authentication-Results:; dkim=none
Received: from Tylan ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x4AB6c1Q002306 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 10 May 2019 11:06:38 GMT
Message-ID: <>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <>
To: Seth Blank <>, IETF DMARC WG <>
Date: Fri, 10 May 2019 11:06:37 +0000
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.33.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.2 at
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [dmarc-ietf] Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 May 2019 11:06:45 -0000

Hello Seth,

> - Definition of "pct" parameter:

The original email is, which references section
5.3 of, which today (Section 6.3 of RFC 7487).

This might be also related to , but it does not contain the word “testing” as

My concerns:

For the purpose of running a test system, one wants to receive all reports, individual or aggregate, whenever a problem
appears.  "p=quarantine; pct=1" would send a report whenever a problem appears, but has as side effect, that some bad
emails (1%) will be quaratined.

This test system is supposed to do MLM rewritings, just as normal NON-test system will do, in order to test the whole
delivery chain.

The combination to have a system, that just sends (individual or aggregate) reports on failures, which does not impact
anyhow mail delivery, is “p=quarantine; pct=0;”.  Currently it is not defined, what that last policy shall mean and
there is not policy that just sends reports, but otherwise 100% delivers the emails properly.  So "p=reject; pct=0;"
just fits.  Now, I do not recall if "p=none;", with or without pct does sends reports…


RFC 6651 defines r=y to send a report whenever a DKIM-Signature fails.  When a MLM rewrites a mail, and changes From:,
DMARC for the new email does validate, however the untouched DKIM-Signature fails.  The current recommendation is to
generate a report for the failed signature.  This report is useless and distracts from useful reports. The report is
useless, because the MLM intentionally broko the DKIM signature and there is nothing the sender of the email can do and
also there is no way how this report can be tackled.

So for DMARC to function fluently, there shall be no distracting DKIM reports.  Whether this is DKIM or DMARC domain
does not matter.  The topic was discussed at ( in
Augist - October 2018.


On Thu, 2019-05-09 at 14:23 -0700, Seth Blank wrote:
> With the group officially in Phase III of the DMARC WG charter, our work is now to explicitly review and refine the DMARC specification, with the goal of generating a standards track document.
> The draft-ietf-dmarc-psd experiment is part of this process, as is the conversation about defining proper ARC reporting XML for DMARC reports.
> This email is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which you believe should be officially discussed as part of the DMARCbis process. Please start a separate thread for each item you have. I'll make sure all are properly in the issue tracker and get addressed.
> Please send in your items no later than *Friday, May 24th*. After this point, we'll be focusing on progressing the DMARCbis process, not gathering new issues.
> Below are a list of nits already in the datatracker. I'll be kicking off threads for several other issues I'm aware of shortly.
> Thanks everyone!
> Seth, as Secretary
> Active issues for DMARCbis in the data tracker:
> - SPF 4408 vs 7208:
> - Flow of operations text:
> - Two tiny nits in 6.6.2 and 6.6.3:
> - Definition of "fo" parameter:
> - Definition of "pct" parameter:
> - Fuzzy normative language around filenames:
> - ABNF for dmarc-record is slightly wrong:
> - Perverse incentives to use p!=none & pct=0:
> - objection to maintaining registry for all participating public suffixes:
> - Link to "URI" reference broken in several sections:
> _______________________________________________
> dmarc mailing list