Re: [dmarc-ietf] Two new fields in aggregate reports

Дилян Палаузов <> Fri, 25 October 2019 10:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DA54120850 for <>; Fri, 25 Oct 2019 03:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, SPF_NONE=0.001, 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 ieux2J0PmxwQ for <>; Fri, 25 Oct 2019 03:52:06 -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 41C0F12084F for <>; Fri, 25 Oct 2019 03:52:05 -0700 (PDT)
Authentication-Results:; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1572000721;; r=y; bh=mCYgJ1FPQdd1IT1MVIJywNW4llOJmiHgxOW8h63yEXw=; h=Subject:From:To:Date:In-Reply-To:References; b=MenyqMvqadxGzTvVdlyGIhqv5sMwDBoERZ/uV9/OeLQfPqkismDpu1lchFZzcPS7m PfDECARzWBHeMhcY9l5si7TiPjeD2CU7OHAMIrcLs3tdfkPue4m6+HITRdpVEvyHei YOZ1M0F3+uWMETf/F2VsOnSx/TbRb2LaNLIDprj3hp3sdXaaR6eBQx78eLz9oUhSK6 aVwn6/tVOkxXUYAbe69JDSdmnBAlcJ216TitMIxWrDGxbeKzsO2ciLC1euTJ8ghPTw UVfx78KfuEQIHnngDcD0fi13vX/l6MpnsGt8v1Vgyj9r9QTw5OfS4yTNgjtouQKD9f EuEzB9KC60xNsJkxlPmixiMX5J8eqtTuaOQzAjPoSBMN2Q53j9GTGpxN7FP75MsFMw s34WXYKB3qlcFoflHiQu1LjU3a1pXjNt5k2hpn+iB7S/I3N/SQiD6t+oJkr3SDHhuH kHSAGlZkb/T7iEuwUcuVUo/LP3sV4qU+H33QuVbuADmaJFjmjmfTPNatumIqErmswX Evo/AMAaAcJDR4XAiqM6IJ6635JcDcEE7Lc4bpYdXy/CciyuNhfKHdpttA6Gar9q93 41A6tJzf1C4T7JpO6zkok8wcbsPpmKsd1Cz5QcXBoTDQ5f+tOc/0Ail0AeCfrNjEyk SUEI6flVXWGK4T+NRIrV9VJ4=
Authentication-Results:; dkim=none
Received: from Tylan ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x9PApn9C007232 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Oct 2019 10:51:55 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: Alessandro Vesely <>, "" <>
Date: Fri, 25 Oct 2019 10:51:43 +0000
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.35.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.4 at
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [dmarc-ietf] Two new fields in aggregate reports
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, 25 Oct 2019 10:52:09 -0000

Hello Alessandro,

I do not see how this helps for DMARC.  An email either validates DMARC, or fails DMARC and the aggregate repors say per
sending IP server (only direct mail flow is reported), whether DMARC validates or fails.  With this information it is
sufficient to determine, if the DMARC/DKIM implementations on sender and receiver are either both bug-free,  or both
have the same bugs.

I do not see, how the information you ask to add, while interesting, does help DMARC.

What is the purposes of the aggregate and non-aggregate reports?  What are non-goals?  I asked several times here,
nobody answered.  Perhaps a discussion on the goals and non-goal would help.

If it is a goal to reuse the dmarc-reporting mechanism to report also about perceived spam probability, then it can be
discussed in more details how this can be achieved.  My experience is, that asking a provider, why an obviously non-spam 
mail was evaluated as spam, virtually never leads to a useful answer.  So nobody wants to reveal how its spam system
weigths factors and if there is lack of such interest, extending the report format will not help, as nobody will be
willing the report the data.

Exchanging information on hard-coded rules in Spam-Assassing (IP reputation, HTML mime part without text/plain, the
“Nigeria money” phrase), that is not based on filter training, does not help neither, as sender can run the tests on its
own and predict how the recipient will evaluate these set of criteria.


On Thu, 2019-10-24 at 19:53 +0200, Alessandro Vesely wrote:
> Hi all,
> it is difficult to tell what is each aggregate report's record.  It is easier
> if the source IP is known.  Mailing lists can be told by their (unaligned) SPF
> domain.  Otherwise, it is difficult to tell abuse from legitimate users using
> the wrong server.
> Getting a failure report for each source IP is not easy, because few mailbox
> providers send failure reports.
> In order to ease the understanding of aggregate reports, I propose two
> additional per-record fields:
> *score*:  The average score of the messages in the row; let's say an SA-like
> number (< 0 good, > 10 bad, values in between may be worth human inspection).
> *list*:  An enumerated type, for example "none", "black", "white", "both",
> indicating if the source IP is listed in some public or private DNSxL that the
> reporting MTA uses.
> They're obviously subjective stuff.  However, most MTAs deploy at least one of
> them, and summing up per-IP results every day can bring useful indications.
> I haven't added those fields to, yet.  Let's
> discuss.  I hope they will make it to rfc7489bis.
> Best
> Ale