Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

Alessandro Vesely <> Thu, 24 December 2020 11:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 867353A11C4 for <>; Thu, 24 Dec 2020 03:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cn3BGd2Yh93P for <>; Thu, 24 Dec 2020 03:31:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11A403A11C2 for <>; Thu, 24 Dec 2020 03:31:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1608809464; bh=aQUbUHAfcVGcCZAlTYU49CgNrg+JSmgPzPbUbWRO9b4=; l=2698; h=To:References:From:Date:In-Reply-To; b=AoaE0M7CvR7RA55yxEHhE189g7C3wq35vVPaOsV11JwxOcEGlUF58ADGXKwMx5Q2v eaEygMTvRBpKkwzMlX1J6OFLnFKitjehsdfGzL3j7vH8U7iTrRxvt4DjllHX2fNvCH 0/5XXb/XAxkevSfOVupznCLuVTZFM4fSIS9HHs+Kr96HBsto8w9MQrNTycs0m
Authentication-Results:; auth=pass (details omitted)
Original-From: Alessandro Vesely <>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC053.000000005FE47BF8.00004008; Thu, 24 Dec 2020 12:31:04 +0100
References: <> <> <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Thu, 24 Dec 2020 12:31:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
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: Thu, 24 Dec 2020 11:31:13 -0000

On Mon 07/Dec/2020 23:17:16 +0100 Marc Bradshaw wrote:
> There is value in including these in one report, especially where the extended 
> property being reported on influences how DMARC is evaluated.

I think I represent a meagre minority of people who reads individual DMARC 
reports.  Most other people I heard of pour their reports into a database and 
then query the latter.  For them, it is indifferent whether reports come in a 
single file or spread among multiple ones.

> Using ARC as the example, when a p=reject policy was overridden by the receiver 
> because of an ARC evaluation, when that data is included in the report the 
> indirect mail flow can be clearly seen, which would not be the case if ARC were 
> included as a separate report.

When I look at an aggregate record whose relaying IP is, SPF domain 
is, and some DKIM signatures are also tagged, it is clear to 
me that it is an indirect mail flow.

Sometimes I get:

If I had a separated ARC file keyed on relaying IPs, I could have found ARC 
values in there and matched them against that row in the DMARC report.

> This could be included in an <extension> element, or could be included directly 
> in the auth_results section of the report, based on an assumption that the 
> things being reported SHOULD have an authentication results entry in processed 
> mail.
> <auth_results>
> <dkim>...</dkim>
> <spf>...</spf>
> <arc> (as defined in arc standard) </arc>
> <foo> (as defined in foo standard) </foo>
> </auth_results>

Say you have:

What would that mean?  Perhaps that, according to, the message did 
pass, but by what authentication method?

An <arc> stanza in auth_results would have to be succinct.  If there is more 
structured data, auth_results doesn't seem to be the right place to stuff it.

I'd propose to first define what data ARC would report.  How to report it comes 

> These would be defined in a registry with reference to each standard, and 
> parsers would ignore any sections they did not understand.

I'd hope we'll come out with proper XML syntax, a namespace like, say, 
urn:ietf:params:xml:ns:dmarc:aggregate:1.1 or some such, and a proper schema 
location.  I think the <selector> element of <dkim> has to become mandatory, 
which makes a difference between reports using a pre-standardization schema and 
upgraded ones.  Then, an XML schema can import other schemata, but dependencies 
and increased complexity will have to be weighted in.