[dmarc-ietf] spec nit - subdomains reporting clarity

Tomki <tki@tomki.com> Sat, 22 June 2019 01:04 UTC

Return-Path: <prvs=06951022f=tki@tomki.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2F66912017F for <dmarc@ietfa.amsl.com>; Fri, 21 Jun 2019 18:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.654
X-Spam-Status: No, score=-0.654 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_BL_SPAMCOP_NET=1.347, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tomki.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ptUyl4SXOTHk for <dmarc@ietfa.amsl.com>; Fri, 21 Jun 2019 18:04:26 -0700 (PDT)
Received: from athena.vistabroadband.net (athena.vistabroadband.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C07120073 for <dmarc@ietf.org>; Fri, 21 Jun 2019 18:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomki.com; l=1655; q=dns/txt; s=tomki; t=1561165466; x=1561338266; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; z=To:=20dmarc@ietf.org|Cc:=20seth@sethblank.com|From:=20To mki=20<tki@tomki.com>|Subject:=20spec=20nit=20-=20subdoma ins=20reporting=20clarity|Message-ID:=20<c8e932fc-5048-77 79-4d8f-31198c205b2a@tomki.com>|Date:=20Fri,=2021=20Jun =202019=2018:04:28=20-0700|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit; bh=iw/l6FTIDbM2FF+XhQlCp8kJCnm9b7xUeLtBl7vrDXY=; b=KVm3SvBROig+uuDzMVHdGcARTvfhl8oh3kuTlJZ4pas5SH9WKg11T/j9 7fLcvoX6SXmd6h+NxWYS9t6JbBnGjPh0AZvvpfxvqI4qz8J3KVPL2C4Op u8fCN9KBLvo7RaftzHmjX4yHFHTPd7q3flkomzJBwhko844efPjIriZV7 LpoZcSfn9YvHoXTP+igaLLYIiI2KMVi/mtBMKCZ1ef6TMZe9iU5K978AH 0tIeH0bp2jVYRn/2bXS7cKsCSK7iCldWqcBFhhsGaHUxnY5ntRKr6Dj7u 17glf7u5FE4FEMXWXAnqA4vCdiFdUSpvM8ny4opPG7vokxS/qhw/Xgc1p g==;
IronPort-SDR: sscXiAbaoOSND9nMY5oFsypsVcDFJCLDZbFJZZmbcoap8DYPnXcpiq7B9wopOj2Sw1iVYyMKlf 4QHWVa+AqADWmDIDC3aYBABw5g77BUj1/+acGMkHchhVPMvoqRVuCZNeOaWwMIHD296TJeDI2e 0wa/nuB9+mm0NwGp8BqbV8Dk5etImeNfEUS2ErBwpquuLVrV6cMgXYsa9aKuDHISImsZGzWT4r sYihfIGEZrAqeWRWJQkJzzKzHJhQeg0Ax6SGRz3Xi5+Zh6ZAzu535WyTx7Ou0N4qgbLxu5041J BZs=
X-SBRS: -10.0
X-recvListener: Inbound
X-sendergroup: RELAYLIST
X-remote-hostname: 75-105-60-135.cust.exede.net
X-IronPort-AV: E=Sophos;i="5.63,402,1557212400"; d="scan'208";a="45039421"
Received: from 75-105-60-135.cust.exede.net (HELO borage.ViaSatDomain) ([]) by athena.vistabroadband.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2019 18:04:20 -0700
To: dmarc@ietf.org
Cc: seth@sethblank.com
From: Tomki <tki@tomki.com>
Message-ID: <c8e932fc-5048-7779-4d8f-31198c205b2a@tomki.com>
Date: Fri, 21 Jun 2019 18:04:28 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw>
Subject: [dmarc-ietf] spec nit - subdomains reporting clarity
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 22 Jun 2019 01:04:28 -0000

The spec appears to be unclear on how subdomains are to be reported - ie 
most but not all implementations have performed this as intended, in the 
same XML as the top level domain (when the subdomain does not have its 
own DMARC TXT record)

Cisco interpreted the current definition to mean that every subdomain 
seen should get its own XML file. (not just the ones with their own 
DMARC record)  This results in every individual IronPort system [which 
has DMARC reporting enabled] generating hundreds to thousands of extra 
reports every day.
This can result in corporate reporters like Paypal or Rolls Royce 
(IronPort users) sending as many reports in a given day as Google.

The section which should be referred to in implementing a reporting 
engine is 7.2 https://tools.ietf.org/html/rfc7489#section-7.2
The only relevant bullet that I find here is
" The report SHOULD include the following data:"
   "Data for each Domain Owner's subdomain separately from mail from
       the sender's Organizational Domain, even if there is no explicit
       subdomain policy"

In trying to find out why Cisco implemented their reporting in the way 
that they did, I've actually had a hard time understanding how others 
understood that bullet point well enough - I can only imagine that 
everybody just implemented by following examples of existing 

A suggested rewording for that bullet point:
" Data for each Domain Owner's subdomains as separate records in a 
report titled for the Organizational Domain, unless there is an explicit 
subdomain policy - in which case a standalone report is generated for 
that subdomain"