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

Alessandro Vesely <> Fri, 25 October 2019 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A831A12003E for <>; Fri, 25 Oct 2019 11:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.001
X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1152-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KYBT8CzAXB5n for <>; Fri, 25 Oct 2019 11:35:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 278BC120033 for <>; Fri, 25 Oct 2019 11:35:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1572028550; bh=6vvVdObkRFsHFxnesRqqBDU1C2kU3seYhbd4Q3iwJtE=; l=3143; h=To:References:From:Date:In-Reply-To; b=DCmaI9hmJiLB2Cc8OBvwQFv1IQ8aatWCzPup2pMffF98YJCicg02CcWZz8wnRUKJL LG7ZBGE/oJ1182l4rO54O+lF3G//om11JyE9npP0bnZJE091B+Xici+RVt3OmeivS6 nh4jVGchbU9wyEIwGFQVIrOGN1LLPbaSvzlXnGVvDNCFDPgXqlqlipLoMQUED
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA id 00000000005DC028.000000005DB34086.00000D3E; Fri, 25 Oct 2019 20:35:50 +0200
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <>, "" <>
References: <> <>
From: Alessandro Vesely <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Fri, 25 Oct 2019 20:35:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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 18:35:57 -0000

Hi Dilyan,

On Fri 25/Oct/2019 12:51:43 +0200 Дилян Палаузов wrote:
> 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.

Looking at aggregate reports, you cannot tell whether an authentication failure
is a sacrosanct signaling of your domain being abused rather than a legitimate
user going through external forwarders.

> 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.

That was probably discussed already.  Now that we have some experience, we can
discuss further.

I know some very acknowledgeable WG participants accumulate aggregate report
values in their own MySQL database (I'm not sure about the details).  Many
people, instead, outsource reports to specialized DMARC analyzers, who display
nice graphical summaries.  I run an XSLT transform of DMARC reports into an
HTML tabular format of one row per record.

In theory, reports can be something more than a debugging aid.  It has the
potential to assemble a community where bad actors are identified and dismissed.

> 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.

Well, spam score usually is hight for phishing too.  To counter phishing is
DMARC core business.

> 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.

This is a problem, indeed.  Large mailbox providers may fear that giving bad
scores to an IP can result in senders complaining against against their
weighting method, requiring more personnel to answer back.  It should be made
clear that reports are given out AS IS, as a favor to senders, without liability.

Anyway, reporting MTAs don't have to reveal the method, just the result.

> 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.

Changing point of view, perspective also changes.  In addition, by comparing
external scores to internal predictions, one has a chance to evaluate the
goodness of the reporting MTA.