Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

"Brotman, Alex" <Alex_Brotman@comcast.com> Wed, 28 April 2021 12:57 UTC

Return-Path: <Alex_Brotman@comcast.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D833A0033; Wed, 28 Apr 2021 05:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8MasLLPVN_V; Wed, 28 Apr 2021 05:57:09 -0700 (PDT)
Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 E05923A040C; Wed, 28 Apr 2021 05:57:08 -0700 (PDT)
Received: from pps.filterd (m0184893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13SCv4YO020690; Wed, 28 Apr 2021 08:57:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=GBhpCfEMvZijtXooT/8lotPckm0mTjZGMTIPAfQ4r3o=; b=VaaSap/Sjxn5K8uVkBFYduuICAzmigAao8+mwBi1inzMkQDIazUgO0ib7E5uUClcC+HQ +SgsMDBZwl8lbq4Y+/NCiKrCduxz+wmWmEibvgZYyBe1/Dl5QzGwyrQHQMv2aiSJ693H /pWls6gw3GO/zLMcAFEBjFZ6ZLjQaP10dCqwlXHnAzJ9WMSAY470LgR8M6PpkEtXSJsY HTCycrbWRxY/sgLxCyeYwjBdeSvM5XIzYFXOv42ExUgmile1XclyRdypZAxavNKOvG1q rRbSuFRmEW58SqaJVtvuPPvvKvlrlmwqiVoHza+0ZFuJEsbq3BUHlKOKz4c+hvd1ME7L QA==
Received: from dlpemail-po-8p.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 386sc2cb2w-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Apr 2021 08:57:07 -0400
Received: from copdcexc33.cable.comcast.com (147.191.125.132) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.4; Wed, 28 Apr 2021 06:57:02 -0600
Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.4 via Frontend Transport; Wed, 28 Apr 2021 06:57:01 -0600
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.176) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 28 Apr 2021 06:56:53 -0600
Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL1PR11MB5335.namprd11.prod.outlook.com (2603:10b6:208:31b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Wed, 28 Apr 2021 12:56:52 +0000
Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8%3]) with mapi id 15.20.4065.026; Wed, 28 Apr 2021 12:56:52 +0000
From: "Brotman, Alex" <Alex_Brotman@comcast.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>, IETF DMARC WG <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Recipient domain in aggregate reports (#23)
Thread-Index: AQHXPAheDLX4tYFQDk2HcDU/HwalU6rJ3YkAgAADluA=
Date: Wed, 28 Apr 2021 12:56:52 +0000
Message-ID: <MN2PR11MB435125AC4DC3D8B21BF290F3F7409@MN2PR11MB4351.namprd11.prod.outlook.com>
References: <f3d272c6-8adf-0797-cb46-c2166a9e292b@wander.science> <CAHej_8kB+B53qFxSAyF9o2mFfC_QXPCobo51cON7ch+UKiKMSw@mail.gmail.com>
In-Reply-To: <CAHej_8kB+B53qFxSAyF9o2mFfC_QXPCobo51cON7ch+UKiKMSw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com;
x-originating-ip: [2601:43:103:e60:5dd:181b:49bb:8f5a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 55761403-90e1-482f-0bb4-08d90a451861
x-ms-traffictypediagnostic: BL1PR11MB5335:
x-microsoft-antispam-prvs: <BL1PR11MB5335F79452ABE201F2C06FF1F7409@BL1PR11MB5335.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1Bsmke1MxrMps3A6+HPwO109VeOZHlzzimNhRuYNEHYy5u6+tYBbJymvS0I6oLbjNfG4mBe5dt87W76dNyxGqIovnj75EKhRtvNxcd3BkYHyB+GPM0fW9FLKA3OI+SIbYHv1r8yRrrj2T7ZuwpFkyPDXG5fniGVgAg5iDcqWI1KWrBKrTdXSj5B5pXRsBkwn/jVXaUaPT8kNtM0SIzRUVXRcG9jB4UXcbH2iUStnIR/IMYAcP3GpPnvGQqrUGtulmQCn5tbYk+BNtKJELkU/kpAm57B3Xt9EJgNW9viDCL66uYeAuFCK5Qi/hXVZxfni6uOmkFdMtGfXF7jfkvW/XAXhaQNwKs0oZ+S9QhWiTfWbT+ioeVzCdNZuxJ4xKJwk5ymIjQfID1w+wdHRP+RLUu5PT39cfEcuBf05p2/NZFNWkTK3JZM1PrtBgKP3jKbfLvOJJc2SCzbmqb4HZHfl5QXrrQKRKxLxE7Ck98vRr2e0Zqh1cP21I4oLqzIL4nDMFYPZgL/8Zyb6gO3l30Y2t9WColVB6e5rPquDop5UBXCw9rFAxsBZV+eNlgglRdeM/tZb5S5zxV1GqNmByFlZTohHxYqxk3P85A8DvdtH2Bk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(84050400001)(38100700002)(122000001)(7696005)(6506007)(76116006)(66946007)(66556008)(71200400001)(8676002)(53546011)(66476007)(86362001)(66574015)(2906002)(66446008)(186003)(478600001)(316002)(9686003)(55016002)(110136005)(83380400001)(5660300002)(52536014)(33656002)(8936002)(64756008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?QkJkSVlUNXBPOURlNENEYnBabzFhRmRtOXlLUWFEVy9NbzhkYnNOd2FwRzgw?= =?utf-8?B?WUxIMytSTUJsaDRBYVZNSlZMaXlRc0JZbit0Z0t1dCtlZG5EbEFlTFo2aThq?= =?utf-8?B?ZjcrS2dpMGJ1VWRBNWlaWWdRZmRrT0J3SDVWK0M3NlRNRVVjV1FXaG13dXFM?= =?utf-8?B?ZjJpN0VSbkszaVUyZmY3Y0pobTZ1d2xEVE8vVTlVbjNNZlFuQUk1K0xlSHlS?= =?utf-8?B?RFVva3RjUlEvVjV4QVp2ZGdSckM0WXBLTUczSTQyQmlkTTkvOWkzYVVBbzlw?= =?utf-8?B?V2s5WCtUbnNseW91N0h2WE5kUDRKYytqREJ1dFUyZW5hNDU3b05BNkkzSzdk?= =?utf-8?B?Ky9tNy9Pa2JSS3lLWHVCVWY4MVlOcmFTaHoyY1pGQ1pHcUhjR2JlbUxDSi9X?= =?utf-8?B?MnVQa2puamZQQ25CZ2tERVF2K240Y0gvbm9DcDdiOTZpS2dWWWpxTk5kQzlR?= =?utf-8?B?YWNwUGNLTU55d2VNQ2JiRjZ6SlU3dUY0dUY5VExDSG5ESDRXRWpsam96aVgr?= =?utf-8?B?QmJ4M2dNYUhxa0sweWRZTFBJN1RWeVZEN3BxUEx4VWtaZkU1dzNjczJwT0FZ?= =?utf-8?B?aWk2WmFQQ0F1SXQ2Nkt3SjEyemtOQm9QUkRyRWxiRGFRZC9rRE9NdEE0YVNM?= =?utf-8?B?dTRkV0lFNnRrWEFUcEhPamR3S2lZeXIrQkhXVCtGcnZpNWZ6K2tlSmY1N21D?= =?utf-8?B?QVZTbUtGZzllT1B5d2V5UzlVRzE5Z3NUQmU0TWFhbUZVS2dFUXljTXNWVXBF?= =?utf-8?B?dHNIK1pjclMyMnR6YTNyOW5ldDE1OGtCditHOHBGaU5taFJibTRuRW9rbzE1?= =?utf-8?B?bE1HVzZyTVVUM2padE5lMEpsTnEzblorRk9qMkV2Y2FhY2w3T0IzcVFUelNG?= =?utf-8?B?YWhlckpWYUplaE5UUERyVm5NTHhNQVdWT1lleU9HMHFObnJoakZDNTF2NDFW?= =?utf-8?B?ejVjWlRqNHVYTmRZM3V1VVNKeTB5VmFxVzhmNTdnZU15S2tWaThEdnYwMEVV?= =?utf-8?B?R1RKYjkzYVdEZVBlZUQ2V1JaRGhWOHlpcy9TRjJ0bk1lT01WZ0JudkYzNXhW?= =?utf-8?B?RFltWWRVdlpxV0p5M2hUMXBZOGZkaFFZZmcvd0d3YWVmdkVvQWw0bEhYK2pY?= =?utf-8?B?a1hTTFE5dGlZWVJjWlg1Nnh3RFkvdzNlRHNzMjYvLzdlTWJOaGJtT0l4VS9Q?= =?utf-8?B?S3Erb0hxSUlRQzE3bm9lMnhJaDF6TkEvcGJvcXlQdVY1SGVqRE85YzBLWEps?= =?utf-8?B?Y2xRVnFhVnNZajhBRUFoWWhJSnE0RUxSWXFTc1NwUzg4R3ZaZENUak5WQUIr?= =?utf-8?B?aTc0THRseGJ1YllocGNQek9XbXp1RWtiUkR2OHZ4YSt6aGxrR00yTEVDS2Fl?= =?utf-8?B?bTluWUlBRmxPdDZlOGl4T05tMG9HMUx3dTFHMXJ6cHhOUU11bXlIdnh6bUpK?= =?utf-8?B?bW5DL29YbXRnWDNBRTYydzNrNkNPTytCMDYyeDVESERvTm9sOGN2VlFDRFBV?= =?utf-8?B?YzlLSW9IV2xwZjdZeElDbDFVSHcrWXVrQ0ZmQ0hUR1hBQjh6VXgxTzIxVEdQ?= =?utf-8?B?WHVJT1hJSGYxK09DMERBSVRkTENyRzlGd3FlNzNFVGdkY3hRaTh4M2FVM1J6?= =?utf-8?B?d0MrNFl2bDhKcTZqQnZEV1RNTGFtdi9Ta2VPeUFFUC84OHRrNXllWUM3S01j?= =?utf-8?B?Z2J4ODJvY1owM0pSMjRHSnlFRVZRY3gzektrZmthQ1JVbUZuejhJU2dsbkJ1?= =?utf-8?B?SjUvajh0b3REbGtsVkgxMTBOZjFjTXZIVDV4ZjFOSDRwUjZqdFdDSFRjSkdw?= =?utf-8?Q?J8vZ/71UW0LG3TqFHkIIwss1tEYHNy4wtMyBk=3D?=
x-ms-exchange-transport-forked: True
arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C3aCxhUVP4iCsJ5LrSrrhhHa2mRsAj4hGo/Pqm9ePRMSz6Hy0v/hYkjJEeKct/IY6R/Lb/py7q7bWtwDsFSPrLnyRaOs4Bn8DcS5w0ZWrasK86wGy9d5aYg5lsxiobHSMVYopwLyfz0xpyoIA+hKFa2RzI8EVnG7brfCylBJA5Gh/vRYsGJ37hirI2vfx9mv7BFWG2/pV9wsGV/hDIqkmgui7fE2AKn3ziheIKIvio7G0x8XgtTKZhE99cv8hVgRGgm8YFqbpqPIkHEkVZh4sfiUGUktcym7cEWVBay7kvRH/lX1pgeliyUamAzyViMIMdmomzjZIWa+SVsYAZW/Yg==
arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EORxK+T3u0F2xEEsKO+BxCb7SIVgVn/iDlInrMm93yo=; b=jbx2LMV4HbAnAHnPpWVEccOSyCb9kidtAVNHF41wN6ZD41V/neNtArPaxPKhM6Ae/TVL5CNTffPzesCxdA1kwuO3wrNlBtBFeDThv2drJBFhGH2ySrlTS5XOu24YNMXeA/ZnSaDHIt8ZR3j2njaFF8VqhFs0cUgZOvIfuvH8Lh85HCHxYGItzJOESZ9IcxuI2vdQcDWQfpjEVVJTZLTYRiiaKbEIXYnCuKkrlnp9am/ixkP1zyWmwHuOfHzRic0yArCoNlMv9n95TVAmChSF0zNtsQiJlaj7/ETSkY9HG9n/AW1syIt3STfI7c7diGqXHt4A5xZX3uphS3UCT7wa/Q==
arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none
x-ms-exchange-crosstenant-authas: Internal
x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com
x-ms-exchange-crosstenant-network-message-id: 55761403-90e1-482f-0bb4-08d90a451861
x-ms-exchange-crosstenant-originalarrivaltime: 28 Apr 2021 12:56:52.6540 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: CQh3OCbeRyvdy15dLVbqB4gYgW6JniRBlfzRDiRr5SRjUadj4raEKkKM/94I2dCM6JKybK93N5PY5E+KaQRlPOubCwYX59ZY2znWV3WSMak=
x-ms-exchange-transport-crosstenantheadersstamped: BL1PR11MB5335
x-originatororg: comcast.com
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB435125AC4DC3D8B21BF290F3F7409MN2PR11MB4351namp_"
MIME-Version: 1.0
X-CFilter-Loop: Forward AAETWM
X-Proofpoint-ORIG-GUID: nDPqnpgB_xXHycp0K5A9i_TzPoVEIddK
X-Proofpoint-GUID: nDPqnpgB_xXHycp0K5A9i_TzPoVEIddK
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-28_06:2021-04-27, 2021-04-28 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/b4zF_9EUYjx5b-ZQt8U-Yse-j_E>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
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: Wed, 28 Apr 2021 12:57:14 -0000

Matt,

While, yes, there is the existing envelope_to, there was a request to add this to the report format (which I believe I did as the submitter desired).  I would assume we’d hash it out on the list and remove one of them.

However, from an operator side of things, I tend to align with Todd on this.  Could someone provide a real-world example of where reporting the destination domain assisted them in resolving an issue?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Todd Herr
Sent: Wednesday, April 28, 2021 8:34 AM
To: IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

Apologies to Matt; I sent this originally only to him when I meant to send it to the list...

On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander <mail=40wander.science@dmarc.ietf.org<mailto:40wander.science@dmarc.ietf.org>> wrote:
Hello everyone,

I'm new to the party. I'd like to bring in some practical experience of
working with DMARC rua reports.

#23 introduces "receiving_domains" in the report metadata, justified by
large infrastructures that host a large number of domains (e.g. Google).

I think, this information would be more useful per-record rather than in
the global metadata. As large infrastructures tend to include many
different records in the report, the analyst needs a correlation between
record and recipient domain.

The <identifiers> section has an optional "envelope_to" already:
>        <!-- The envelope recipient domain. -->
>        <xs:element name="envelope_to" type="xs:string"
>                    minOccurs="0"/>

Is there a benefit in the global "receiving_domains" over the per-record
"envelope_to"?

Most reporters don't include "envelope_to" (e.g. Google). This field
could be made more prominent in the draft. The main body mentions
"header_from" only, but neither "envelope_to" nor "envelope_from".

There is a hole in my understanding of this topic that I'm hoping someone can fill here, and that hole is this: I don't understand the value of reporting out receiving domains.

The reason I don't understand it is because my expectation as a sender receiving a report about my sending domain would be that my DMARC validation results from a given receiving infrastructure would generally not vary across the different receiving domains, regardless of if there was one domain, ten domains, or ten thousand domains hosted by the reporting infrastructure. To extend my expectations further, unless I'm dedicating part of my infrastructure to sending solely to one and only one receiving site, I would expect my DMARC validation results to generally not vary across different reporting infrastructures. I'm declaring here that "DMARC validation results" are separate from "applied receiver handling policy" because as a sender I can only control the former; "DMARC validation results" means "whether or not SPF and/or DKIM passed and was aligned and consequently resulted in a DMARC pass or fail".

If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly, receiving_domains, defined as the "List of domains which received messages for the domain in this report" I guess it could perhaps help me as a report consumer in the case where I receive a report from an previously unknown or unfamiliar to me reporter that hosts many domains, and if that's the use case, then perhaps the field ought to be amended to "List of the top $SMALL_NUMBER domains which received messages for the domain in this report" because as a report consumer I don't need to see 837 domains listed when realistically one or two will suffice.

What is the value that I'm not seeing in reporting out receiving domains?
--
Todd Herr | Sr. Technical Program Manager
e: todd.herr@valimail.com<mailto:todd.herr@valimail.com>
m: 703.220.4153


This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.