From William.Weist@iqvia.com Mon Nov 4 09:17:42 2019 Return-Path: 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 5A16F120824 for ; Mon, 4 Nov 2019 09:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tVlJnVMN-9qN for ; Mon, 4 Nov 2019 09:17:39 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760090.outbound.protection.outlook.com [40.107.76.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39725120BB4 for ; Mon, 4 Nov 2019 09:17:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E6Nk/TdD3bvzfesKr0fqGPSP+lb+oEQoHWNLQE5qhPiIWzrSXJIrIDa2g9vieduiuwqQqScxp/VGGpW1PNaHzWVadN2zT+tK8JMGc9BRRYAm1q3jYvNDQ+4BJOuyKcXe+Djer/ZnupZv+cMb8Zkz8Pp9PWQsJBAMZgVmOnzNUnpXPkJt25vRph6JA0bykNoLImvXreZmL8OaGswaTc7KdUon3mJVuBVrUchpagOry+NvMoV4CzfWaw/01u9/YQkPETy7nuyWCQziR5MPur43IETrwpZR5fjLNCN4okKS0ZWUOu/QYZLgTz26adGgbddp+Cu/5n2ZlCSSzGp44p2d5w== 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=DoJ7L4lhi/eiZEE37b7KKDEbEuWMLTE3/+1ZDhuxY84=; b=KMmUXUmHP4u+IdIpRi3KPK0F60HbtyT0wyQPSt7nmhC2XNdf07BHLazW7j70p62byUN42/6CE2TWkoPgMKjryFgzgsy0UKMTyUBlU5AnbpdA9GjEEJ3Vwq8QUHMwkPaM7L+EaXoaSWwcuLwDdxLmh1x6maP1rAu458etdp5iv9ddRcw2qJe/9RTtwrP7SVqb7PG+DgrzbUSc0sLl3Ccf3yybzFPYOEoSmzXpkLwt5OmgxL+GTekdhkCobkgj2foB0ZTj8mJHtGDeyu7BmLSc+FJG3sigRenvlX23/l0Se3NH0MlbQXp8tjhOBwSyRdpo61KEANkFBX7KmlI6Jo7NkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iqvia.com; dmarc=pass action=none header.from=iqvia.com; dkim=pass header.d=iqvia.com; arc=none Received: from BN7PR05MB4163.namprd05.prod.outlook.com (52.132.217.155) by BN7PR05MB4323.namprd05.prod.outlook.com (52.135.249.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Mon, 4 Nov 2019 17:17:36 +0000 Received: from BN7PR05MB4163.namprd05.prod.outlook.com ([fe80::64ec:6de1:44c6:c7b8]) by BN7PR05MB4163.namprd05.prod.outlook.com ([fe80::64ec:6de1:44c6:c7b8%6]) with mapi id 15.20.2430.013; Mon, 4 Nov 2019 17:17:35 +0000 From: "Weist, Bill" To: "dmarc@ietf.org" Thread-Topic: Question regarding RFC 8617 Thread-Index: AdWTMguQWnkvj8CtSAGz9qIfZtaWOQ== Date: Mon, 4 Nov 2019 17:17:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.700.9 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=William.Weist@iqvia.com; x-originating-ip: [192.69.82.131] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2073f4fb-4256-48a7-29a2-08d7614ae2fe x-ms-traffictypediagnostic: BN7PR05MB4323: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(346002)(136003)(366004)(376002)(51744003)(189003)(199004)(8936002)(8676002)(54896002)(7066003)(1730700003)(6916009)(14444005)(256004)(606006)(71200400001)(99286004)(102836004)(74316002)(14454004)(45080400002)(99936001)(7696005)(26005)(7736002)(71190400001)(478600001)(861006)(66066001)(81156014)(81166006)(7116003)(2351001)(5024004)(6506007)(316002)(86362001)(33656002)(6306002)(55016002)(5640700003)(5660300002)(3846002)(6116002)(790700001)(76116006)(66946007)(2501003)(966005)(66446008)(64756008)(66556008)(66476007)(66616009)(476003)(186003)(236005)(486006)(25786009)(733005)(9686003)(6436002)(2906002)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4323; H:BN7PR05MB4163.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iqvia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AAWDouhLSjQVqDGS1+qVEEx4WV4HnKMVwYovoj+ppxq1fjy0A7UcAGuCHosHaUOV4TX6jSlHkqsF9Bxg+itY8x//ygOsszD1RufnrRcTKhhVmtgVqEh+EanAtQw+2TUCgZqSkK8C4D1APLtSc5P5aTQrYMeA58BpuPBK7deY8gzuu7UJyIdLyELKKKoKbYNJTbB5MgXW0Ny24wScPCu7zrbAyBZJORWlMjFJLeA4xRylfwBe3B1zj+eSr7+MqmJQGD2mCHiXIJ+CXnoZCMsuYSkgu2O1d6LYW9+X/TIIp1M7313nRyL+rimQI8Y81uF8kraWWrxIGDD5VDUW5HwCh5VHaIAMkrQmtXZrqDii/kv6v7VFjF3JhzaSD7lkS9b5bT52rbrQW24wwfVo5TtPt9gaX2azrakIaDs0wa7k1d5ihT7Rm2OMU64zRjsHz2ZUdVyEsaXAKdhEwf+fO17sgqC1KtqbFKIgPTIQpXtIxaU= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: iqvia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2073f4fb-4256-48a7-29a2-08d7614ae2fe X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 17:17:35.6988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5989ece0-f90e-40bf-9c79-1a7beccdb861 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xbdTwAld4d3Io4eNGgDLFUAPa4JkcLw7m0K0NT5QcQpO2l+u8WLEBUgmEhptZYXeQydVNDyoLWSt11kVszmPng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4323 Archived-At: X-Mailman-Approved-At: Wed, 06 Nov 2019 07:30:19 -0800 Subject: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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: Mon, 04 Nov 2019 19:22:56 -0000 --_004_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_ Content-Type: multipart/alternative; boundary="_000_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_" --_000_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DOI: 10.17487/RFC8617 The inclusion of the address headers in the signature, and possibly the Sub= ject, is an issue: ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dmicr= osoft.com; s=3Darcselector9901; h=3DFrom:Date:Subject:Message-ID:Content-Ty= pe:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3D; If a downstream server needs to modify either of these two values, the sign= ature check fails. It is my understanding that the Authenticated Received Check signature is t= o validate the chain of possession. As such, in my opinion, the signature = should only include immutable references. In my opinion, there is value in NOT requiring headers to be stripped by do= wnstream servers, thus maintaining the custody chain from origination to de= stination. Thank you for your time and attention, William M. Weist Enterprise Architect I - Global Messaging - Mobile and Presence CIO Team - End User Computing [IQVIA logo_96dpi_100pxheight] Learn more about IQVIA(tm) 400 Campus Drive Collegeville, PA 19426 USA O: +1 610 244 2646 | M: +1 484 904 8244 ________________________________________ IMPORTANT - PLEASE READ: This electronic message, including its attachments= , is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY PRIVILEGED or PROT= ECTED information and is intended for the authorized recipient of the sende= r. If you are not the intended recipient, you are hereby notified that any = use, disclosure, copying, or distribution of this message or any of the inf= ormation included in it is unauthorized and strictly prohibited. If you hav= e received this message in error, please immediately notify the sender by r= eply e-mail and permanently delete this message and its attachments, along = with any copies thereof, from all locations received (e.g., computer, mobil= e device, etc.). To the extent permitted by law, we may monitor electronic = communications for the purposes of ensuring compliance with our legal and r= egulatory obligations and internal policies. We may also collect email traf= fic headers for analyzing patterns of network traffic and managing client r= elationships. For further information see: https://www.iqvia.com/about-us/p= rivacy/privacy-policy. Thank you. --_000_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

DOI:  10.17487/RFC8617

 

The inclusion of the address headers in the signatur= e, and possibly the Subject, is an issue:

 

ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Dre= laxed/relaxed; d=3Dmicrosoft.com; s=3Darcselector9901; h=3DFrom:Date:Subject:Message-ID:Content-Type:= MIME-Version:X-MS-Exchange-SenderADCheck; bh=3D;

 

If a downstream server needs to modify either of the= se two values, the signature check fails.

 

It is my understanding that the Authenticated Receiv= ed Check signature is to validate the chain of possession.  As such, i= n my opinion, the signature should only include immutable references.<= /o:p>

 

In my opinion, there is value in NOT requiring heade= rs to be stripped by downstream servers, thus maintaining the custody chain= from origination to destination.

 

Thank you for your time and attention,

 

William M. Weist=

Enterprise Archi= tect I – Global Messaging – Mobile and Presence

CIO Team – En= d User Computing

3D"IQVIA

Learn more about IQVIA&= #8482;

 

400 Campus Drive

Collegeville, PA 194= 26

USA

 

O: +1 610 244 26= 46 | M: +1 484 904 8244

 



________________________________________
IMPORTANT - PLEASE READ: This electron= ic message, including its attachments, is CONFIDENTIAL and may contain PROP= RIETARY or LEGALLY PRIVILEGED or PROTECTED information and is intended for the authorized recipient of the sender. If= you are not the intended recipient, you are hereby notified that any use, = disclosure, copying, or distribution of this message or any of the informat= ion included in it is unauthorized and strictly prohibited. If you have received this message in error, pleas= e immediately notify the sender by reply e-mail and permanently delete this= message and its attachments, along with any copies thereof, from all locat= ions received (e.g., computer, mobile device, etc.). To the extent permitted by law, we may monitor electronic c= ommunications for the purposes of ensuring compliance with our legal and re= gulatory obligations and internal policies. We may also collect email traff= ic headers for analyzing patterns of network traffic and managing client relationships. For further informat= ion see: https://www.iqvia.com/about-us/privacy/privacy-policy. Thank you.

--_000_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_-- --_004_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6018; creation-date="Mon, 04 Nov 2019 17:17:35 GMT"; modification-date="Mon, 04 Nov 2019 17:17:35 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABkANUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKo65qB0jRr++CeabW3knCE43bVLYz74ry/wn8dp9e+I2k+HLzQhYafqnh+11W31QXQdTdSo0j2 hXAwVjQuGz8wDcDHOkacppuPQzlUjFpPqevUV8/2v7Tl3qOj398NAttJtj4lTQ7DUNUvtlobZ4PO jvbhwv7pJB8qLzlnjBI3cekeIPHV/wCEfhXqHinVrSxN3Y2j3UsNreF7Zgp+8spUfKV+bJHFaSoV INKS3IjWhO9nsdxRXnd18a/D8fjKy0e31TS7uxfSrzVLvUIb9HW1WB4V+YLnAPmnkkY2981tR/E7 w1NpMupJqe+2inFtIqwSmZJSu4IYtu8Er8wG3kc9KzdOas2i1Ug20nsdVRXl/if456T4XuJr+aSO 88NrpEGpR3lkGleRpbjyVCgcFeh/OrVn8adDXxvqWhahqNnZBfsJsGferzC5QlN+RhNzqVXOMkY6 1XsZ2vb+v6Ye0he1z0aivK/jN8ZLj4X32i2lvp1teT6lFcPbpdXPlNeTRBCtlbqAS9xKGYouMYjb JrqvG/j+08EeDbzX5oJL0wmOCOytmUyzXMkixRwAk7QzSOqckAE80vZTtF2+LYPaRV79NzqqK81h +IHijw3rWg2vjHRNOs7PWpDaxXmkXklwtpciN5BFNvjXKlY3AkHG4AEDIrY1j4naJa+Gzqdhqum3 Hm6b/ats1zcmKGW2yo84uFbCfOvzYP3hQ6U7pW3Eqke52VFci3xX8JL4hl0I69af2vFM1tJaBiWW ZYhMYjxjzPLO8J94ryARXJyfHux1jwTceIvDwtriFdJ1K/jh1B3hmaS1AIUR7fmQ5+ZgRtyvBzwK lN9AdSEd2etUVytn8R9Ck1Gy0q41GGLV51jBtgGwsjxh1jLY2hypyFJ3Ec4q94c8a6L4skuU0i/j vjbkeYY1YDBJAZSQAykqRuXI4PPFS4yWrRfNF9TcorkZfix4St4dUmn1y2tYNLiae7luN0SRRK21 pNzAAoG4LDIB6mlHxV8KG4sof7ahEl4I2i3I4GHYrGWJGE3sCF3Y3ds0ezn2Fzx7nW0Vy3iz4n+F vA90ltr2uWmmXDW7XYjmY7vJVgrykAHCKWXcx4XIyRTr74meF9N16HRbnW7WHUpWiRYSxIDSf6pW YDarP/CpILds0ck7XsHPHa509FczD8SvC89xY26a7Yme+gubm2i80B5Yrdglw4B5xGxAb0JxW7pu o22r6fa31nMtxaXUSzQzJ910YAqw9iCDScWt0VdPYs0UUVIwooooAKKKKAKOt6edX0e/sQ/lG6t5 IPMxnbuUrnHfGa8l1f8AZ2OreHJ9OHiO4sLo2OlWltqFnCFmtns1dHkXJP8ArY5HQjsGPNeyTTJb wvLIwSNFLMzdAAMk15pa/tKfDi9mMdv4nt5nAzhY5DwO/wB2uyhDESTlRi2lvZXt6nHXq4anKMa8 0m9ru1/QlX4Y6noLa8/h3UdNgi1O9gn+wajp5ntxbx2kdv8AZ8K6nH7oPu/DBqHSvgsul/BW68Aj U1b7VHcK9wtsFhiM0rSskUO4hIl3FUjydqgDJxVz/hf/AID/AOhgi/79Sf8AxNcv4i/bM+DnhLUf sGseOLPTrsoJBFPFKpZT/EPl5H0q1DFS91Qb26dvkJSw17qS69e+5ufET4G6f48vFkjuI9IiGl3N gVtrVQS8ksEiSEjGQrQfd7hjyKz2+C2rtbidNZsrLUpNSjvL1bO3nSG/hSFo1hnYzGVgpbzAQ4GV VSCuQdP4X/tJfDX4zaxd6V4N8WWWu6jawfapbaDcHWLdt34YDI3YH4itf4ufFC0+EfhI69e2U9/C J44BDbkBstnnJ44ANOEMVKpHDKL5nok139Sa1TDUaU8TUlaMdW+1vQ4+z/Z9nsfB76NDr6iddF/s uK6Nn8qyC5a4SUpv5XJAKZ6DrW7rPwnuvEFvr7XeqQpeaxJpk0zw2pCI9o6OdoLE4Yrxk/LnvXoV ndLe2cFwgISVFkAbrgjI/nXN/ED4neHfhjpYvtf1BbVX4ihQF5piOoRBycdz0HesoOvWqKEFeTey Wt/6RpUlQw9J1KslGKWrbsrHJ/E/4K3Pj7X7rULfV4bRL7To9Nm+02zSy2XlytIlzZuHXyZgXJ3c 5KRn+DBuad8F4F+D6eAtR1KSdIV/dataxLDc+akvmxXTZ3KbgSBZGbGGcE7QDivPP+Gyba63T6f4 E8Q32nA/8fSIMY9eAR+tehfC/wDaD8JfFaX7Lp11JZaqF3HT75dkpA67Tkq+O+Dkd69Otl+Y4elz VKbUY69Hb1tt8zxsPm+U4qt7OlVTlLbdX9L2v8jP1D4X+NvEHiXw5e634w0u/wBM0WZp1sYdGeE3 ErRtF5rsJyN6pI+0AbQzbsHAxk2v7PerN4dbRr7xRBNbW/h5/Ddk8Wn7HWHzY3SaQ7zuk2xqpA2q TyAM4r2LxBqw0HQ9Q1I2812LO3kuPs9uMySbFLbVHcnGBXn/AOzv8fdF/aK+H8fibSLWfTJFma3u 9Nu3RprWQYIDFSQQylWBHUNXnKdZwdSPwq3Redv1PZdOip8r3d+r8v8AgF64+FZmu5JxqKqX8Tx+ IseR/diWPys577Pve+MVg/8ACjb+40GTSrrX4Xjj0/WNMtZY7Iqyw3rKVLguQzx7cEjAb0FewU2R 1jVmZgqqMlmOAB61gq01szZ0oPdHkNr8Bfsni6e/+2WV5pN3qVvrFxa3trJJItzFDHGpjIlCAboY 3DMjMpBAOCNu/wDDX4caj4J1HV57jV4pLO7VEh0uwgaG0gZWctMkbu+x33gMqkJ8gIUEnOD8Cf2k tG+P2s+MrbQtKv4NP8PXi2iapOUa3vwd3zxlSSB8ucNztZW6NVj4gftCaZ8PfjL4D+Hl1pN9d3vi 0SmG+gZBDbbOm8E7juII+UHHeumUcQ5OjJa2202Sv+XzMIOgoqrF6N7+r/zMCP8AZx1G7+1HVfFP 9pTSaXcaWbqa2Z5bhZbiKbzZS0hG791t2oFT5jgdAOg8TfBP+3PGmpasl1ZyafrEtrLqFnf28s3z QBQvl7ZVXkKv31baRuHpXqtLWH1ipe9zVUaa0scR4o+HP/CSeINS1I3qwi88P3Gh+WYQ23zX3eZn POP7veuVm+BupY1LTLfxBDF4e1i7s77UYjYBrrzYI4UKxS7sKri3j+8rMnzbTyu2n+0F+1b4X/Z4 1fw1p2s2l3qNxq8u6VbNkH2G1DBXuZNxGVBYfKPmOGIHBr2i2uYry3ingkWWGVA6SIchlIyCD6EV f76lCM2rJ7fIm1KpJxvqt9e54l4h/ZpbWbzxFcQeJprGTUNSjurFktEJ061dg19aoc8rclpizHkG QY+4K9ttreO1gjhiQRxRqERFGAqgYA/KuA1/4rS+FdYNvqOjk2H25rI3ltciQx/6P5yyOhUEAkpH gZIZx2ya6zwfrz+KPC+lavJZyadJe20c72crh3gZlBKMRwSp4JHHFTUdWUU57fL+un9XKh7OMmo7 /wBf5/1Y2KKKK5jcKKKKACub+IGr+IND8M3F34Z0WPX9WR0CWMk4hDKWAY7j6DnFdJXnPxY+FzeP ms7tvF+teGIbCKQyDS5/LRwcEs/uAP1NdeFVN1o+1do+abXpZWeu2hw411lh5+wTcraWaT9U2mtN 9Uzm9O+IXxburdzefDi1tn3Y8v7crZGOuQfrWWsXitJDIvwg0FXJzuHlg1x+mX3gGaNLe3+M+s3D In3t7liBxknFXv8AijP+iva1/wB9P/hXs1qbp1JJU+W/Tlmvzdzw8PUVWlFurztdeam9fVK33HTe Z4x/6JJof/fUdct8QF8fLpUd1pfwD8L+I9QjkVBbXckKYjJ+YqxB6enen/8AFGf9Fe1r/vp/8K5b 4mXXw5t/CNymr/HzXvDdrM6RjUIZ2jkRt2QFYqeTjH0rOnH317v4T/RnS5X0Uvxh/keifs23nj6b xJq6eKvgtoPwzsfsiGK/0q6ikkuZN5/dFUXO0DnJPWrP7av/ACRg/wDYRg/k1cP+x/L8Pj401seE fjxrvxTvXsFMml6reebHBGJP9cqlRzkhcg9xXcftq/8AJGT/ANhGD+TV04KPLnFFWt70ejX/AKVd nJnF/wCw8Um9eSXZ9PJL8j2TTr2LTfCltdztthgskldvRVjBP6Cvm/4K+Dx8f/FurfEjxdD9r09b k2+madNzEFU5GV7qoI+XoW3E54x77q+ny6t8L7uyg5muNIaJB6sYcCvMP2Mtatr34QR6ch23mm3k 0VxERhlLNvUkfQ4/A1lhZSoYLEV6Xx3jG/VRd7/e0kTjoQxWZ4TDV9afLOVukpR5Ur97JtnusVvH bwrFEixxqMBEUBQPTArwz9or4K2mqaHdeL/DkA0zxVpQ+2CazGxrhU5OcfxgDKt14wcgmvd84rnP iLr1p4a8C69qV64S2t7KVmz3JUgKPckgfjXl4HEVsPiITo73Wnfyfe57OZ4XD4vCTp4j4Um7/wAt luuzRj/BP4gN8TvhppGuTBReSIYboKML5yHa5A9CRn8a+UbFv+GPP2ypLJj9l+HXxGO+LtFbXTPw OvG2V8f7s6dkr3j9jfS7jTfgrZyTqyi6u5541YY+TdtBHsdpNH7YnwOHxz+DOpafawh/EGm51HSm zgmZFO6PPYSIWT6kHtXp1fY4bMK2G/5dNuPpro/kzzcHKvjMqw2Kl/FUYy9XbX/wJHuNfM37dnxm ufh/8M4fCmgPI/i7xhJ/ZtnDbtiVYWIWV1wcgtuWNT/ekB7Gtr9j349xfFr4HwX2tXQi13w8hsdZ af5WBjXKzMMcbkAY+jBh2rxr9ne1uP2qv2nPEPxj1OJm8J+G3+weHYZR8rOAdjgeoRmkPH3plHVK 5cPhvYVpzrrSnv5vovn+R6NfEKtShCi9am3kur+X5n0n+zX8GbX4E/CPRvDMaxm/VPtOozxjAmun AMh+g4UeiqBXg/7S/wDyfJ+z1/22/wDQmr7Jr42/aX/5Pk/Z6/7bf+hNU4KpKriJzm7txn/6SzTF QjToRhFaJx/9KR9k1R13WrLw3ot9qupXKWmn2MD3NxPI2FjjRSzMT7AVer49/bw+IWp+Jbjw18D/ AAlJv8Q+LbiM3uw58q13fKr89GKs7A9Uicd64sNQeIqqnsur7LqzpxFb2FJz3fTzfRHl/wAN/hBd ftyeIPij8S/EXm2Wn3cUmk+FxIDiCRAfLcj+IRgjI6F5ZQegr2j9gX4sX2veB9S+G/iXfB4s8ETG xkhmbLtbBiqc99jK0ee4VT/FXq/w61P4cfB3wTpPgzT/ABTodtBo8ItWWTUIlkaQf6xn+b77NuJz 3NfMn7RV5a/BD48+Ffj94PurfVPDOpT/ANl+JP7NlWWNm2gMSVyMtGoPrvgjH8Ve37X6854a1o/Y 8rLRfNfieOqX1PkxF7y+3536/wDbr/A+6WtYZGLNEjHOcsoPOMZ/SnxxrGoVFCKOiqMAVX0vU7XW tNtb+ynW5s7qJZoZozlXRgCrA+hBq3XzfkfQhRRRSAKKKKACkZQ6lWAZSMEEZBpaKAPHfifp2reF 7zTx4O+F+jeJIpUc3EziKExMCMLg4zkEnPtWHb3njaS3jaT4RaLHIygsmY/lPcV77j2owPSvR+uX pxg4Jtdbyu/XW33JHlLAuNWVRVWk/s2jZenu3+9s8G+0eMv+iS6L/wCQ68/8feIvizHqaWmk/s4e H/ENhGgdri7uYI18w9lU5PA7nFfXO0elG0elTHFKLu6af/gX6M2eFb/5eP8A8l/yPnv9m/UPH934 k1dfFnwX0P4aWItEMWoaXcxPJcSbz+6KoM4A5zmr37ZttNdfBtkghknf+0IPljQsedwHT3IH417t j2pGUMMEZHvWlDG+xxcMUoL3WnZN9PN3ZjjMD9bwVTBufxpq9l18lYpaEjR6Lp6spVlt4wVIwQdo 4r568dfC7xf8J/H1147+G8X9oWV5l9S0HGdxJy21eNyk5bj5lJOMgkV9KUlThcbPCVJSik4y0aez X9bMWPy2lj6cYTbjKDvGS0cX3X6p6M+TfHn7U1n4u8D6r4bv/C/iLQ9avrYwDyF/1cnbk7WK56jG SM1yHw8h8bftERad4I1LVxY+H/DyxtfM24XUq5IXIbl3GCoJwF4JycV9utbxu4do1Zh0YqCa5zS/ ht4f0fxpqXiuz09Ydc1GMRXNwHbDKMfw5wCcDJHXAr3aOcYXD0ZwoUOSW8XfmtLbra2nrrbQ+XxH D2NxWIhUxWK9pD4ZK3JeG9nyt3963RaXV0bejaRaaBpVppthAttZWsSwwwp0VFGAKuGlor5Jtyd3 ufexiopRirJH5rftUfCnxh8J/jHreneAIbhdD+LMQsmtbaBmj+0NJ+9hJUfuwS5l3f3Wm7CvvD4K fC3T/gz8M9D8J6fh1sYf38+MG4nb5pZT7s5Jrt2QMQSASDkcdKdXoYjGzxFKFKS238+iv6LQ4aGD hQqyqJ77eXV29XqFfHv7SGn3dz+29+z5NDZ3M0Ki4LTRwO8abSSdzAYXAPcivsKmlAzBiASOhx0r nw9b2E3O19GvvTX6nRWpKtFRb6p/c7lPWtTXRdHvtQkilnS1gknaKFSzuFUttUDqTjgV8ffsS+Dt W+KXjjxZ8ffF1pNDqGszyWui29zGymC34DsobBACqkQ452Ow4evs6kVFjUBQAB2AxTp13SpThFay sr+XVfPQmpRVSpCcnpHW3n3+R80ah/wTr+CWpaleXsmgX8ct1cSXMixanMq75HLtgbuBuY8ds11N r+yB8PtB+Dfin4d6Dp0mn6XrzNcyzSzNNKt1tURzBnzgoUQjH92vcKSrljcTJJSqN2830EsLQTbU Fd76dz5U/YF8WeI7bwn4k+GniqwurfVPA179hS4khdYmhYsVjV2ABCkHbjP7toz3r6spoUKxIGCe vvTqyxFVV6sqiVr/ANP8S6FN0aapt3sFFFFc5uFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//Z --_004_BN7PR05MB416368F6F754F6B6E0095648FA7F0BN7PR05MB4163namp_-- From nobody Wed Nov 6 07:36:56 2019 Return-Path: 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 ACFA612008D for ; Wed, 6 Nov 2019 07:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLACK=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 djcND3W5I-Yi for ; Wed, 6 Nov 2019 07:36:52 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785A712004C for ; Wed, 6 Nov 2019 07:36:52 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id s3so23642910ioe.3 for ; Wed, 06 Nov 2019 07:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uOR2zjnpSdh3giRKrSB3cN5+7bsYZPFxSeTDvy9L1nE=; b=cK+gT49HvgOi9sV1HV8J6Q+G1zJIDxGchPLMh/YVMaIz/JGRkZXXWaU849Tkm+QHOe tqR3p/eeNx/GPAHS7GIPKfDi1G8wNzashRroU25AjBwE8z7jmcKe8bysQk9m/98Rt7+Y LQHOsLAQ+5oiN/IN3PWpMtFVpGKmN2sX0YHoY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uOR2zjnpSdh3giRKrSB3cN5+7bsYZPFxSeTDvy9L1nE=; b=VTW9/ZY2Wqmqr8trMKmmgNUag1R3WvgLgMzZysS75yT1iMamrsOX54T0118wHBoEAY +sIt7Iq3FyYvUugxJ6xl2Qi7J/mizjISa7M8T3aqjreeyAagrFoMBCmz/B+yWGW89/KD CYb+i56SgTsCd0WQS0E9jBuDdxuJZejmE9YuSe2B8D7NWYA+l2BX8KHNgXjgbheWGZnO hS7C8EF4z+HgAPmruhgvq2vgEhoN94kkwdruY7cNmU1oIISzl97c5lGzWoo8jUuGYsX0 4JASav9EGjcqoV6AQimDGE6GbbB9/8oAtcMCX+OHMMhQr2FDatJhgNsKYBXXTZ0oeC1T NAxQ== X-Gm-Message-State: APjAAAVkE7B36ZxXWv+fyaJBLlAcHzey22rohKHbkQB3ja92P7T5s5KE NkEwJVOFvcYrTHHLoXaH9suFgov5dRajR0c5km85aw== X-Google-Smtp-Source: APXvYqyJDu4HZjS/FKQOwBpZzQvuqZPyqKQUSn+x8celV66yTdOwmSqqGf1fs7ffwvJ9IY83pAXpYgBv6ziqc7Aur4M= X-Received: by 2002:a5d:8987:: with SMTP id m7mr2183072iol.104.1573054611497; Wed, 06 Nov 2019 07:36:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Wed, 6 Nov 2019 07:36:37 -0800 Message-ID: To: "Weist, Bill" Cc: "dmarc@ietf.org" Content-Type: multipart/related; boundary="00000000000054d6bb0596af5144" Archived-At: Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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: Wed, 06 Nov 2019 15:36:55 -0000 --00000000000054d6bb0596af5144 Content-Type: multipart/alternative; boundary="00000000000054d6ba0596af5143" --00000000000054d6ba0596af5143 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The choice of which headers are included in the signed set is strictly up to the domain administrators who implement the signing practices. Also, the AMS is only relevant for the next receiver, it is not intended to be validated by hops >1 step away from the domain which adds that instance so I don't see how mutability would matter. --Kurt Andersen On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill wrote: > DOI: 10.17487/RFC8617 > > > > The inclusion of the address headers in the signature, and possibly the > Subject, is an issue: > > > > ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D > microsoft.com; s=3Darcselector9901; h=3DFrom:Date:Subject:Message-ID:Cont= ent-Type:MIME-Version:X-MS-Exchange-SenderADCheck; > bh=3D; > > > > If a downstream server needs to modify either of these two values, the > signature check fails. > > > > It is my understanding that the Authenticated Received Check signature is > to validate the chain of possession. As such, in my opinion, the signatu= re > should only include immutable references. > > > > In my opinion, there is value in NOT requiring headers to be stripped by > downstream servers, thus maintaining the custody chain from origination t= o > destination. > > > > Thank you for your time and attention, > > > > *William M. Weist* > > *Enterprise Architect I =E2=80=93 Global Messaging =E2=80=93 Mobile and P= resence* > > CIO Team =E2=80=93 End User Computing > > *[image: IQVIA logo_96dpi_100pxheight]* > > Learn more about IQVIA=E2=84=A2 > > > > 400 Campus Drive > > Collegeville, PA 19426 > > USA > > > > O: +1 610 244 2646 | M: +1 484 904 8244 > > > > > ________________________________________ > *IMPORTANT* - PLEASE READ: This electronic message, including its > attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY > PRIVILEGED or PROTECTED information and is intended for the authorized > recipient of the sender. If you are not the intended recipient, you are > hereby notified that any use, disclosure, copying, or distribution of thi= s > message or any of the information included in it is unauthorized and > strictly prohibited. If you have received this message in error, please > immediately notify the sender by reply e-mail and permanently delete this > message and its attachments, along with any copies thereof, from all > locations received (e.g., computer, mobile device, etc.). To the extent > permitted by law, we may monitor electronic communications for the purpos= es > of ensuring compliance with our legal and regulatory obligations and > internal policies. We may also collect email traffic headers for analyzin= g > patterns of network traffic and managing client relationships. For furthe= r > information see: https://www.iqvia.com/about-us/privacy/privacy-policy. > Thank you. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000054d6ba0596af5143 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The choice of which headers are included in the signed set= is strictly up to the domain administrators who implement the signing prac= tices. Also, the AMS is only relevant for the next receiver, it is not inte= nded to be validated by hops >1 step away from the domain which adds tha= t instance so I don't see how mutability would matter.

--Kurt Andersen

On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill <William.Weist@iqvia.com> wrot= e:

DOI:=C2=A0 10.17487/RFC8617

=C2=A0

The inclusion of the address headers in the signatur= e, and possibly the Subject, is an issue:

=C2=A0

ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Dre= laxed/relaxed; d=3Dmicro= soft.com; s=3Darcselector9901; h=3DFr= om:Date:Subject:Message-ID:= Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3D;

=C2=A0

If a downstream server needs to modify either of the= se two values, the signature check fails.

=C2=A0

It is my understanding that the Authenticated Receiv= ed Check signature is to validate the chain of possession.=C2=A0 As such, i= n my opinion, the signature should only include immutable references.

=C2=A0

In my opinion, there is value in NOT requiring heade= rs to be stripped by downstream servers, thus maintaining the custody chain= from origination to destination.

=C2=A0

Thank you for your time and attention,=

=C2=A0

William M. Weist

Enterprise Archite= ct I =E2=80=93 Global Messaging =E2=80=93 Mobile and Presence=

CIO Team =E2=80=93 En= d User Computing

3D"I=

Learn more<= /a> about IQVIA=E2=84=A2=

=C2=A0

400 Campus Drive

Collegeville, PA 19426=

USA

=C2=A0

O: +1 610 244 2646 | M= : +1 484 904 8244

=C2=A0



________________________________________
IMPORTANT - PLEASE READ: Th= is electronic message, including its attachments, is CONFIDENTIAL and may c= ontain PROPRIETARY or LEGALLY PRIVILEGED or PROTECTED information and is intended for the authorized recipient of the sender. If= you are not the intended recipient, you are hereby notified that any use, = disclosure, copying, or distribution of this message or any of the informat= ion included in it is unauthorized and strictly prohibited. If you have received this message in error, pleas= e immediately notify the sender by reply e-mail and permanently delete this= message and its attachments, along with any copies thereof, from all locat= ions received (e.g., computer, mobile device, etc.). To the extent permitted by law, we may monitor electronic c= ommunications for the purposes of ensuring compliance with our legal and re= gulatory obligations and internal policies. We may also collect email traff= ic headers for analyzing patterns of network traffic and managing client relationships. For further informat= ion see: https://www.iqvia.com/about-us/privacy/privacy-policy= . Thank you.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000054d6ba0596af5143-- --00000000000054d6bb0596af5144 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <16e4159f0a74ce8e91> X-Attachment-Id: 16e4159f0a74ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABkANUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKo65qB0jRr++CeabW3knCE43bVLYz74ry/wn8dp9e+I2k+HLzQhYafqnh+11W31QXQdTdSo0j2 hXAwVjQuGz8wDcDHOkacppuPQzlUjFpPqevUV8/2v7Tl3qOj398NAttJtj4lTQ7DUNUvtlobZ4PO jvbhwv7pJB8qLzlnjBI3cekeIPHV/wCEfhXqHinVrSxN3Y2j3UsNreF7Zgp+8spUfKV+bJHFaSoV INKS3IjWhO9nsdxRXnd18a/D8fjKy0e31TS7uxfSrzVLvUIb9HW1WB4V+YLnAPmnkkY2981tR/E7 w1NpMupJqe+2inFtIqwSmZJSu4IYtu8Er8wG3kc9KzdOas2i1Ug20nsdVRXl/if456T4XuJr+aSO 88NrpEGpR3lkGleRpbjyVCgcFeh/OrVn8adDXxvqWhahqNnZBfsJsGferzC5QlN+RhNzqVXOMkY6 1XsZ2vb+v6Ye0he1z0aivK/jN8ZLj4X32i2lvp1teT6lFcPbpdXPlNeTRBCtlbqAS9xKGYouMYjb JrqvG/j+08EeDbzX5oJL0wmOCOytmUyzXMkixRwAk7QzSOqckAE80vZTtF2+LYPaRV79NzqqK81h +IHijw3rWg2vjHRNOs7PWpDaxXmkXklwtpciN5BFNvjXKlY3AkHG4AEDIrY1j4naJa+Gzqdhqum3 Hm6b/ats1zcmKGW2yo84uFbCfOvzYP3hQ6U7pW3Eqke52VFci3xX8JL4hl0I69af2vFM1tJaBiWW ZYhMYjxjzPLO8J94ryARXJyfHux1jwTceIvDwtriFdJ1K/jh1B3hmaS1AIUR7fmQ5+ZgRtyvBzwK lN9AdSEd2etUVytn8R9Ck1Gy0q41GGLV51jBtgGwsjxh1jLY2hypyFJ3Ec4q94c8a6L4skuU0i/j vjbkeYY1YDBJAZSQAykqRuXI4PPFS4yWrRfNF9TcorkZfix4St4dUmn1y2tYNLiae7luN0SRRK21 pNzAAoG4LDIB6mlHxV8KG4sof7ahEl4I2i3I4GHYrGWJGE3sCF3Y3ds0ezn2Fzx7nW0Vy3iz4n+F vA90ltr2uWmmXDW7XYjmY7vJVgrykAHCKWXcx4XIyRTr74meF9N16HRbnW7WHUpWiRYSxIDSf6pW YDarP/CpILds0ck7XsHPHa509FczD8SvC89xY26a7Yme+gubm2i80B5Yrdglw4B5xGxAb0JxW7pu o22r6fa31nMtxaXUSzQzJ910YAqw9iCDScWt0VdPYs0UUVIwooooAKKKKAKOt6edX0e/sQ/lG6t5 IPMxnbuUrnHfGa8l1f8AZ2OreHJ9OHiO4sLo2OlWltqFnCFmtns1dHkXJP8ArY5HQjsGPNeyTTJb wvLIwSNFLMzdAAMk15pa/tKfDi9mMdv4nt5nAzhY5DwO/wB2uyhDESTlRi2lvZXt6nHXq4anKMa8 0m9ru1/QlX4Y6noLa8/h3UdNgi1O9gn+wajp5ntxbx2kdv8AZ8K6nH7oPu/DBqHSvgsul/BW68Aj U1b7VHcK9wtsFhiM0rSskUO4hIl3FUjydqgDJxVz/hf/AID/AOhgi/79Sf8AxNcv4i/bM+DnhLUf sGseOLPTrsoJBFPFKpZT/EPl5H0q1DFS91Qb26dvkJSw17qS69e+5ufET4G6f48vFkjuI9IiGl3N gVtrVQS8ksEiSEjGQrQfd7hjyKz2+C2rtbidNZsrLUpNSjvL1bO3nSG/hSFo1hnYzGVgpbzAQ4GV VSCuQdP4X/tJfDX4zaxd6V4N8WWWu6jawfapbaDcHWLdt34YDI3YH4itf4ufFC0+EfhI69e2U9/C J44BDbkBstnnJ44ANOEMVKpHDKL5nok139Sa1TDUaU8TUlaMdW+1vQ4+z/Z9nsfB76NDr6iddF/s uK6Nn8qyC5a4SUpv5XJAKZ6DrW7rPwnuvEFvr7XeqQpeaxJpk0zw2pCI9o6OdoLE4Yrxk/LnvXoV ndLe2cFwgISVFkAbrgjI/nXN/ED4neHfhjpYvtf1BbVX4ihQF5piOoRBycdz0HesoOvWqKEFeTey Wt/6RpUlQw9J1KslGKWrbsrHJ/E/4K3Pj7X7rULfV4bRL7To9Nm+02zSy2XlytIlzZuHXyZgXJ3c 5KRn+DBuad8F4F+D6eAtR1KSdIV/dataxLDc+akvmxXTZ3KbgSBZGbGGcE7QDivPP+Gyba63T6f4 E8Q32nA/8fSIMY9eAR+tehfC/wDaD8JfFaX7Lp11JZaqF3HT75dkpA67Tkq+O+Dkd69Otl+Y4elz VKbUY69Hb1tt8zxsPm+U4qt7OlVTlLbdX9L2v8jP1D4X+NvEHiXw5e634w0u/wBM0WZp1sYdGeE3 ErRtF5rsJyN6pI+0AbQzbsHAxk2v7PerN4dbRr7xRBNbW/h5/Ddk8Wn7HWHzY3SaQ7zuk2xqpA2q TyAM4r2LxBqw0HQ9Q1I2812LO3kuPs9uMySbFLbVHcnGBXn/AOzv8fdF/aK+H8fibSLWfTJFma3u 9Nu3RprWQYIDFSQQylWBHUNXnKdZwdSPwq3Redv1PZdOip8r3d+r8v8AgF64+FZmu5JxqKqX8Tx+ IseR/diWPys577Pve+MVg/8ACjb+40GTSrrX4Xjj0/WNMtZY7Iqyw3rKVLguQzx7cEjAb0FewU2R 1jVmZgqqMlmOAB61gq01szZ0oPdHkNr8Bfsni6e/+2WV5pN3qVvrFxa3trJJItzFDHGpjIlCAboY 3DMjMpBAOCNu/wDDX4caj4J1HV57jV4pLO7VEh0uwgaG0gZWctMkbu+x33gMqkJ8gIUEnOD8Cf2k tG+P2s+MrbQtKv4NP8PXi2iapOUa3vwd3zxlSSB8ucNztZW6NVj4gftCaZ8PfjL4D+Hl1pN9d3vi 0SmG+gZBDbbOm8E7juII+UHHeumUcQ5OjJa2202Sv+XzMIOgoqrF6N7+r/zMCP8AZx1G7+1HVfFP 9pTSaXcaWbqa2Z5bhZbiKbzZS0hG791t2oFT5jgdAOg8TfBP+3PGmpasl1ZyafrEtrLqFnf28s3z QBQvl7ZVXkKv31baRuHpXqtLWH1ipe9zVUaa0scR4o+HP/CSeINS1I3qwi88P3Gh+WYQ23zX3eZn POP7veuVm+BupY1LTLfxBDF4e1i7s77UYjYBrrzYI4UKxS7sKri3j+8rMnzbTyu2n+0F+1b4X/Z4 1fw1p2s2l3qNxq8u6VbNkH2G1DBXuZNxGVBYfKPmOGIHBr2i2uYry3ingkWWGVA6SIchlIyCD6EV f76lCM2rJ7fIm1KpJxvqt9e54l4h/ZpbWbzxFcQeJprGTUNSjurFktEJ061dg19aoc8rclpizHkG QY+4K9ttreO1gjhiQRxRqERFGAqgYA/KuA1/4rS+FdYNvqOjk2H25rI3ltciQx/6P5yyOhUEAkpH gZIZx2ya6zwfrz+KPC+lavJZyadJe20c72crh3gZlBKMRwSp4JHHFTUdWUU57fL+un9XKh7OMmo7 /wBf5/1Y2KKKK5jcKKKKACub+IGr+IND8M3F34Z0WPX9WR0CWMk4hDKWAY7j6DnFdJXnPxY+FzeP ms7tvF+teGIbCKQyDS5/LRwcEs/uAP1NdeFVN1o+1do+abXpZWeu2hw411lh5+wTcraWaT9U2mtN 9Uzm9O+IXxburdzefDi1tn3Y8v7crZGOuQfrWWsXitJDIvwg0FXJzuHlg1x+mX3gGaNLe3+M+s3D In3t7liBxknFXv8AijP+iva1/wB9P/hXs1qbp1JJU+W/Tlmvzdzw8PUVWlFurztdeam9fVK33HTe Z4x/6JJof/fUdct8QF8fLpUd1pfwD8L+I9QjkVBbXckKYjJ+YqxB6enen/8AFGf9Fe1r/vp/8K5b 4mXXw5t/CNymr/HzXvDdrM6RjUIZ2jkRt2QFYqeTjH0rOnH317v4T/RnS5X0Uvxh/keifs23nj6b xJq6eKvgtoPwzsfsiGK/0q6ikkuZN5/dFUXO0DnJPWrP7av/ACRg/wDYRg/k1cP+x/L8Pj401seE fjxrvxTvXsFMml6reebHBGJP9cqlRzkhcg9xXcftq/8AJGT/ANhGD+TV04KPLnFFWt70ejX/AKVd nJnF/wCw8Um9eSXZ9PJL8j2TTr2LTfCltdztthgskldvRVjBP6Cvm/4K+Dx8f/FurfEjxdD9r09b k2+madNzEFU5GV7qoI+XoW3E54x77q+ny6t8L7uyg5muNIaJB6sYcCvMP2Mtatr34QR6ch23mm3k 0VxERhlLNvUkfQ4/A1lhZSoYLEV6Xx3jG/VRd7/e0kTjoQxWZ4TDV9afLOVukpR5Ur97JtnusVvH bwrFEixxqMBEUBQPTArwz9or4K2mqaHdeL/DkA0zxVpQ+2CazGxrhU5OcfxgDKt14wcgmvd84rnP iLr1p4a8C69qV64S2t7KVmz3JUgKPckgfjXl4HEVsPiITo73Wnfyfe57OZ4XD4vCTp4j4Um7/wAt luuzRj/BP4gN8TvhppGuTBReSIYboKML5yHa5A9CRn8a+UbFv+GPP2ypLJj9l+HXxGO+LtFbXTPw OvG2V8f7s6dkr3j9jfS7jTfgrZyTqyi6u5541YY+TdtBHsdpNH7YnwOHxz+DOpafawh/EGm51HSm zgmZFO6PPYSIWT6kHtXp1fY4bMK2G/5dNuPpro/kzzcHKvjMqw2Kl/FUYy9XbX/wJHuNfM37dnxm ufh/8M4fCmgPI/i7xhJ/ZtnDbtiVYWIWV1wcgtuWNT/ekB7Gtr9j349xfFr4HwX2tXQi13w8hsdZ af5WBjXKzMMcbkAY+jBh2rxr9ne1uP2qv2nPEPxj1OJm8J+G3+weHYZR8rOAdjgeoRmkPH3plHVK 5cPhvYVpzrrSnv5vovn+R6NfEKtShCi9am3kur+X5n0n+zX8GbX4E/CPRvDMaxm/VPtOozxjAmun AMh+g4UeiqBXg/7S/wDyfJ+z1/22/wDQmr7Jr42/aX/5Pk/Z6/7bf+hNU4KpKriJzm7txn/6SzTF QjToRhFaJx/9KR9k1R13WrLw3ot9qupXKWmn2MD3NxPI2FjjRSzMT7AVer49/bw+IWp+Jbjw18D/ AAlJv8Q+LbiM3uw58q13fKr89GKs7A9Uicd64sNQeIqqnsur7LqzpxFb2FJz3fTzfRHl/wAN/hBd ftyeIPij8S/EXm2Wn3cUmk+FxIDiCRAfLcj+IRgjI6F5ZQegr2j9gX4sX2veB9S+G/iXfB4s8ETG xkhmbLtbBiqc99jK0ee4VT/FXq/w61P4cfB3wTpPgzT/ABTodtBo8ItWWTUIlkaQf6xn+b77NuJz 3NfMn7RV5a/BD48+Ffj94PurfVPDOpT/ANl+JP7NlWWNm2gMSVyMtGoPrvgjH8Ve37X6854a1o/Y 8rLRfNfieOqX1PkxF7y+3536/wDbr/A+6WtYZGLNEjHOcsoPOMZ/SnxxrGoVFCKOiqMAVX0vU7XW tNtb+ynW5s7qJZoZozlXRgCrA+hBq3XzfkfQhRRRSAKKKKACkZQ6lWAZSMEEZBpaKAPHfifp2reF 7zTx4O+F+jeJIpUc3EziKExMCMLg4zkEnPtWHb3njaS3jaT4RaLHIygsmY/lPcV77j2owPSvR+uX pxg4Jtdbyu/XW33JHlLAuNWVRVWk/s2jZenu3+9s8G+0eMv+iS6L/wCQ68/8feIvizHqaWmk/s4e H/ENhGgdri7uYI18w9lU5PA7nFfXO0elG0elTHFKLu6af/gX6M2eFb/5eP8A8l/yPnv9m/UPH934 k1dfFnwX0P4aWItEMWoaXcxPJcSbz+6KoM4A5zmr37ZttNdfBtkghknf+0IPljQsedwHT3IH417t j2pGUMMEZHvWlDG+xxcMUoL3WnZN9PN3ZjjMD9bwVTBufxpq9l18lYpaEjR6Lp6spVlt4wVIwQdo 4r568dfC7xf8J/H1147+G8X9oWV5l9S0HGdxJy21eNyk5bj5lJOMgkV9KUlThcbPCVJSik4y0aez X9bMWPy2lj6cYTbjKDvGS0cX3X6p6M+TfHn7U1n4u8D6r4bv/C/iLQ9avrYwDyF/1cnbk7WK56jG SM1yHw8h8bftERad4I1LVxY+H/DyxtfM24XUq5IXIbl3GCoJwF4JycV9utbxu4do1Zh0YqCa5zS/ ht4f0fxpqXiuz09Ydc1GMRXNwHbDKMfw5wCcDJHXAr3aOcYXD0ZwoUOSW8XfmtLbra2nrrbQ+XxH D2NxWIhUxWK9pD4ZK3JeG9nyt3963RaXV0bejaRaaBpVppthAttZWsSwwwp0VFGAKuGlor5Jtyd3 ufexiopRirJH5rftUfCnxh8J/jHreneAIbhdD+LMQsmtbaBmj+0NJ+9hJUfuwS5l3f3Wm7CvvD4K fC3T/gz8M9D8J6fh1sYf38+MG4nb5pZT7s5Jrt2QMQSASDkcdKdXoYjGzxFKFKS238+iv6LQ4aGD hQqyqJ77eXV29XqFfHv7SGn3dz+29+z5NDZ3M0Ki4LTRwO8abSSdzAYXAPcivsKmlAzBiASOhx0r nw9b2E3O19GvvTX6nRWpKtFRb6p/c7lPWtTXRdHvtQkilnS1gknaKFSzuFUttUDqTjgV8ffsS+Dt W+KXjjxZ8ffF1pNDqGszyWui29zGymC34DsobBACqkQ452Ow4evs6kVFjUBQAB2AxTp13SpThFay sr+XVfPQmpRVSpCcnpHW3n3+R80ah/wTr+CWpaleXsmgX8ct1cSXMixanMq75HLtgbuBuY8ds11N r+yB8PtB+Dfin4d6Dp0mn6XrzNcyzSzNNKt1tURzBnzgoUQjH92vcKSrljcTJJSqN2830EsLQTbU Fd76dz5U/YF8WeI7bwn4k+GniqwurfVPA179hS4khdYmhYsVjV2ABCkHbjP7toz3r6spoUKxIGCe vvTqyxFVV6sqiVr/ANP8S6FN0aapt3sFFFFc5uFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//Z --00000000000054d6bb0596af5144-- From nobody Wed Nov 6 09:43:44 2019 Return-Path: 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 699EF12011C for ; Wed, 6 Nov 2019 09:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17 X-Spam-Level: X-Spam-Status: No, score=-17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLACK=0.5, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 GrjQ9W-b2tCP for ; Wed, 6 Nov 2019 09:43:38 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A49120220 for ; Wed, 6 Nov 2019 09:43:37 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id 190so12008534vss.8 for ; Wed, 06 Nov 2019 09:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pOYk1jkjo+ZxQtpmqFIIFKAcPCb60pFg8KNUqryXseQ=; b=GRs+PM0xDb3wJFR83NT8qt0wwIt+zBUpyyDE1pwOeeeiJzLIpD92KVOj/MulsCs7Rr nFH+tcAVTR2HnJzliUKnbXDLqVUhoYY2LRxqNpmenPLuMYMO38QL5nKth98kcTlWGloN AnPecr/o+mtdJpUCumN9Co7sWgbZyWz1AceE/dp0ws05ljA0Ke8vmNz41rBa1Qfa0mxs H+RGHjesNKag+fbtMEjD82uXSeBNzrSI/q3vsO1shqBJLbVBTmC2H8+owrBxAP1gdUv9 x9gD8/8VJIQ2jJyXE5TcojblxbDvnSbAdwVFnKBbIxB3+ruVqDUO4gX5uTbI6srkRD2C nZbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pOYk1jkjo+ZxQtpmqFIIFKAcPCb60pFg8KNUqryXseQ=; b=ElPKzwsKpyDvRfwTU50f5XZBa/zckFb2axOdf7ZpUp8CicjGy4doC4Lrl8ZnYT309W felu0T8gqQ4QqPr68O4RKAAWUsUQNWXtwVKDyTEug9JKI9ErgUsaTrpzQir8GPZkgx0a ajpBrq1pZ1+VMJELgiWK3I24sEnfLu3p7GxoDT/rPLELOlvB4ovFC49TxByIOU9VaxWE ze4FxLy96P3z3Vm/GaIxj94K9IT/FRhmuaL4N20oIlj+de6dFNWEVyNCFQU7K0YQ7dYB k3vLoqeRuADa2wQQFe3MNox4kuB/1Zxo3VY8R2jTiRMBOQQvbynFO3Fz1M7LuUpBkBD8 11rg== X-Gm-Message-State: APjAAAVdDT9XCaw+423y/Glk93NE3ZN4fYD8hLK22829xCg4/nUtZkIc aCznxrb271Nyyq5AX1GLLvblGQA06f8Zn7KyxFO4 X-Google-Smtp-Source: APXvYqxYhYYcPEN8elor74jnerhxomEkzKoiJ3BWEdMWMgqA0F3TxCm2pyAAotQM+9DlNn0tzNFnlq6xOEzcZ6613FU= X-Received: by 2002:a67:304a:: with SMTP id w71mr1871043vsw.92.1573062216132; Wed, 06 Nov 2019 09:43:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Wed, 6 Nov 2019 09:43:22 -0800 Message-ID: To: "Kurt Andersen (b)" Cc: "Weist, Bill" , "dmarc@ietf.org" Content-Type: multipart/related; boundary="0000000000009b05070596b116c3" Archived-At: Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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: Wed, 06 Nov 2019 17:43:39 -0000 --0000000000009b05070596b116c3 Content-Type: multipart/alternative; boundary="0000000000009b05060596b116c2" --0000000000009b05060596b116c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What's more, the point of including Subject and other mutable headers is the same as it is for DKIM, those are the headers which are important to the receiver, so they should be validated. As Kurt points out, the point of ARC is to acknowledge these changes hop to hop, and the Arc Seal proves who did the change, the question becomes do you believe the person who changed it wasn't malicious. Brandon On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) wrote: > The choice of which headers are included in the signed set is strictly up > to the domain administrators who implement the signing practices. Also, t= he > AMS is only relevant for the next receiver, it is not intended to be > validated by hops >1 step away from the domain which adds that instance s= o > I don't see how mutability would matter. > > --Kurt Andersen > > On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill > wrote: > >> DOI: 10.17487/RFC8617 >> >> >> >> The inclusion of the address headers in the signature, and possibly the >> Subject, is an issue: >> >> >> >> ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D >> microsoft.com; s=3Darcselector9901; h=3DFrom:Date:Subject:Message-ID:Con= tent-Type:MIME-Version:X-MS-Exchange-SenderADCheck; >> bh=3D; >> >> >> >> If a downstream server needs to modify either of these two values, the >> signature check fails. >> >> >> >> It is my understanding that the Authenticated Received Check signature i= s >> to validate the chain of possession. As such, in my opinion, the signat= ure >> should only include immutable references. >> >> >> >> In my opinion, there is value in NOT requiring headers to be stripped by >> downstream servers, thus maintaining the custody chain from origination = to >> destination. >> >> >> >> Thank you for your time and attention, >> >> >> >> *William M. Weist* >> >> *Enterprise Architect I =E2=80=93 Global Messaging =E2=80=93 Mobile and = Presence* >> >> CIO Team =E2=80=93 End User Computing >> >> *[image: IQVIA logo_96dpi_100pxheight]* >> >> Learn more about IQVIA=E2=84=A2 >> >> >> >> 400 Campus Drive >> >> Collegeville, PA 19426 >> >> USA >> >> >> >> O: +1 610 244 2646 <(610)%20244-2646> | M: +1 484 904 8244 >> <(484)%20904-8244> >> >> >> >> >> ________________________________________ >> *IMPORTANT* - PLEASE READ: This electronic message, including its >> attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY >> PRIVILEGED or PROTECTED information and is intended for the authorized >> recipient of the sender. If you are not the intended recipient, you are >> hereby notified that any use, disclosure, copying, or distribution of th= is >> message or any of the information included in it is unauthorized and >> strictly prohibited. If you have received this message in error, please >> immediately notify the sender by reply e-mail and permanently delete thi= s >> message and its attachments, along with any copies thereof, from all >> locations received (e.g., computer, mobile device, etc.). To the extent >> permitted by law, we may monitor electronic communications for the purpo= ses >> of ensuring compliance with our legal and regulatory obligations and >> internal policies. We may also collect email traffic headers for analyzi= ng >> patterns of network traffic and managing client relationships. For furth= er >> information see: https://www.iqvia.com/about-us/privacy/privacy-policy.. >> Thank you. >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000009b05060596b116c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What's more, the point of including Subject and other = mutable headers is the same as it is for DKIM, those are the headers which = are important to the receiver, so they should be validated.=C2=A0=C2=A0
=
As Kurt points out, the point of ARC is to acknowledge these changes ho= p to hop, and the Arc Seal proves who did the change, the question=C2=A0bec= omes do you believe
the person who changed it wasn't malicious.

Brandon

On Wed, Nov 6, 2019 at 7:37 AM Kurt Ande= rsen (b) <kboth@drkurt.com> w= rote:
The choice of which headers are included in the signed set is stri= ctly up to the domain administrators who implement the signing practices. A= lso, the AMS is only relevant for the next receiver, it is not intended to = be validated by hops >1 step away from the domain which adds that instan= ce so I don't see how mutability would matter.

--Kur= t Andersen

On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill <William.Weist@iqvia.com> wrote:

DOI:=C2=A0 10.17487/RFC8617

=C2=A0

The inclusion of the address headers in the signatur= e, and possibly the Subject, is an issue:

=C2=A0

ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Dre= laxed/relaxed; d=3Dmicro= soft.com; s=3Darcselector9901; h=3DFr= om:Date:Subject:Message-ID:= Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3D;

=C2=A0

If a downstream server needs to modify either of the= se two values, the signature check fails.

=C2=A0

It is my understanding that the Authenticated Receiv= ed Check signature is to validate the chain of possession.=C2=A0 As such, i= n my opinion, the signature should only include immutable references.

=C2=A0

In my opinion, there is value in NOT requiring heade= rs to be stripped by downstream servers, thus maintaining the custody chain= from origination to destination.

=C2=A0

Thank you for your time and attention,=

=C2=A0

William M. Weist

Enterprise Archite= ct I =E2=80=93 Global Messaging =E2=80=93 Mobile and Presence=

CIO Team =E2=80=93 En= d User Computing

3D"IQVIA

Learn more<= /a> about IQVIA=E2=84=A2=

=C2=A0

400 Campus Drive

Collegeville, PA 19426=

USA

=C2=A0

O: +1 610 244 2646 = | M: +1 484 904 8244

=C2=A0



________________________________________
IMPORTANT - PLEASE READ: Th= is electronic message, including its attachments, is CONFIDENTIAL and may c= ontain PROPRIETARY or LEGALLY PRIVILEGED or PROTECTED information and is intended for the authorized recipient of the sender. If= you are not the intended recipient, you are hereby notified that any use, = disclosure, copying, or distribution of this message or any of the informat= ion included in it is unauthorized and strictly prohibited. If you have received this message in error, pleas= e immediately notify the sender by reply e-mail and permanently delete this= message and its attachments, along with any copies thereof, from all locat= ions received (e.g., computer, mobile device, etc.). To the extent permitted by law, we may monitor electronic c= ommunications for the purposes of ensuring compliance with our legal and re= gulatory obligations and internal policies. We may also collect email traff= ic headers for analyzing patterns of network traffic and managing client relationships. For further informat= ion see: https://www.iqvia.com/about-us/privacy/privacy-policy= .. Thank you.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000009b05060596b116c2-- --0000000000009b05070596b116c3 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <16e4159f0a74ce8e91> X-Attachment-Id: 16e4159f0a74ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABkANUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKo65qB0jRr++CeabW3knCE43bVLYz74ry/wn8dp9e+I2k+HLzQhYafqnh+11W31QXQdTdSo0j2 hXAwVjQuGz8wDcDHOkacppuPQzlUjFpPqevUV8/2v7Tl3qOj398NAttJtj4lTQ7DUNUvtlobZ4PO jvbhwv7pJB8qLzlnjBI3cekeIPHV/wCEfhXqHinVrSxN3Y2j3UsNreF7Zgp+8spUfKV+bJHFaSoV INKS3IjWhO9nsdxRXnd18a/D8fjKy0e31TS7uxfSrzVLvUIb9HW1WB4V+YLnAPmnkkY2981tR/E7 w1NpMupJqe+2inFtIqwSmZJSu4IYtu8Er8wG3kc9KzdOas2i1Ug20nsdVRXl/if456T4XuJr+aSO 88NrpEGpR3lkGleRpbjyVCgcFeh/OrVn8adDXxvqWhahqNnZBfsJsGferzC5QlN+RhNzqVXOMkY6 1XsZ2vb+v6Ye0he1z0aivK/jN8ZLj4X32i2lvp1teT6lFcPbpdXPlNeTRBCtlbqAS9xKGYouMYjb JrqvG/j+08EeDbzX5oJL0wmOCOytmUyzXMkixRwAk7QzSOqckAE80vZTtF2+LYPaRV79NzqqK81h +IHijw3rWg2vjHRNOs7PWpDaxXmkXklwtpciN5BFNvjXKlY3AkHG4AEDIrY1j4naJa+Gzqdhqum3 Hm6b/ats1zcmKGW2yo84uFbCfOvzYP3hQ6U7pW3Eqke52VFci3xX8JL4hl0I69af2vFM1tJaBiWW ZYhMYjxjzPLO8J94ryARXJyfHux1jwTceIvDwtriFdJ1K/jh1B3hmaS1AIUR7fmQ5+ZgRtyvBzwK lN9AdSEd2etUVytn8R9Ck1Gy0q41GGLV51jBtgGwsjxh1jLY2hypyFJ3Ec4q94c8a6L4skuU0i/j vjbkeYY1YDBJAZSQAykqRuXI4PPFS4yWrRfNF9TcorkZfix4St4dUmn1y2tYNLiae7luN0SRRK21 pNzAAoG4LDIB6mlHxV8KG4sof7ahEl4I2i3I4GHYrGWJGE3sCF3Y3ds0ezn2Fzx7nW0Vy3iz4n+F vA90ltr2uWmmXDW7XYjmY7vJVgrykAHCKWXcx4XIyRTr74meF9N16HRbnW7WHUpWiRYSxIDSf6pW YDarP/CpILds0ck7XsHPHa509FczD8SvC89xY26a7Yme+gubm2i80B5Yrdglw4B5xGxAb0JxW7pu o22r6fa31nMtxaXUSzQzJ910YAqw9iCDScWt0VdPYs0UUVIwooooAKKKKAKOt6edX0e/sQ/lG6t5 IPMxnbuUrnHfGa8l1f8AZ2OreHJ9OHiO4sLo2OlWltqFnCFmtns1dHkXJP8ArY5HQjsGPNeyTTJb wvLIwSNFLMzdAAMk15pa/tKfDi9mMdv4nt5nAzhY5DwO/wB2uyhDESTlRi2lvZXt6nHXq4anKMa8 0m9ru1/QlX4Y6noLa8/h3UdNgi1O9gn+wajp5ntxbx2kdv8AZ8K6nH7oPu/DBqHSvgsul/BW68Aj U1b7VHcK9wtsFhiM0rSskUO4hIl3FUjydqgDJxVz/hf/AID/AOhgi/79Sf8AxNcv4i/bM+DnhLUf sGseOLPTrsoJBFPFKpZT/EPl5H0q1DFS91Qb26dvkJSw17qS69e+5ufET4G6f48vFkjuI9IiGl3N gVtrVQS8ksEiSEjGQrQfd7hjyKz2+C2rtbidNZsrLUpNSjvL1bO3nSG/hSFo1hnYzGVgpbzAQ4GV VSCuQdP4X/tJfDX4zaxd6V4N8WWWu6jawfapbaDcHWLdt34YDI3YH4itf4ufFC0+EfhI69e2U9/C J44BDbkBstnnJ44ANOEMVKpHDKL5nok139Sa1TDUaU8TUlaMdW+1vQ4+z/Z9nsfB76NDr6iddF/s uK6Nn8qyC5a4SUpv5XJAKZ6DrW7rPwnuvEFvr7XeqQpeaxJpk0zw2pCI9o6OdoLE4Yrxk/LnvXoV ndLe2cFwgISVFkAbrgjI/nXN/ED4neHfhjpYvtf1BbVX4ihQF5piOoRBycdz0HesoOvWqKEFeTey Wt/6RpUlQw9J1KslGKWrbsrHJ/E/4K3Pj7X7rULfV4bRL7To9Nm+02zSy2XlytIlzZuHXyZgXJ3c 5KRn+DBuad8F4F+D6eAtR1KSdIV/dataxLDc+akvmxXTZ3KbgSBZGbGGcE7QDivPP+Gyba63T6f4 E8Q32nA/8fSIMY9eAR+tehfC/wDaD8JfFaX7Lp11JZaqF3HT75dkpA67Tkq+O+Dkd69Otl+Y4elz VKbUY69Hb1tt8zxsPm+U4qt7OlVTlLbdX9L2v8jP1D4X+NvEHiXw5e634w0u/wBM0WZp1sYdGeE3 ErRtF5rsJyN6pI+0AbQzbsHAxk2v7PerN4dbRr7xRBNbW/h5/Ddk8Wn7HWHzY3SaQ7zuk2xqpA2q TyAM4r2LxBqw0HQ9Q1I2812LO3kuPs9uMySbFLbVHcnGBXn/AOzv8fdF/aK+H8fibSLWfTJFma3u 9Nu3RprWQYIDFSQQylWBHUNXnKdZwdSPwq3Redv1PZdOip8r3d+r8v8AgF64+FZmu5JxqKqX8Tx+ IseR/diWPys577Pve+MVg/8ACjb+40GTSrrX4Xjj0/WNMtZY7Iqyw3rKVLguQzx7cEjAb0FewU2R 1jVmZgqqMlmOAB61gq01szZ0oPdHkNr8Bfsni6e/+2WV5pN3qVvrFxa3trJJItzFDHGpjIlCAboY 3DMjMpBAOCNu/wDDX4caj4J1HV57jV4pLO7VEh0uwgaG0gZWctMkbu+x33gMqkJ8gIUEnOD8Cf2k tG+P2s+MrbQtKv4NP8PXi2iapOUa3vwd3zxlSSB8ucNztZW6NVj4gftCaZ8PfjL4D+Hl1pN9d3vi 0SmG+gZBDbbOm8E7juII+UHHeumUcQ5OjJa2202Sv+XzMIOgoqrF6N7+r/zMCP8AZx1G7+1HVfFP 9pTSaXcaWbqa2Z5bhZbiKbzZS0hG791t2oFT5jgdAOg8TfBP+3PGmpasl1ZyafrEtrLqFnf28s3z QBQvl7ZVXkKv31baRuHpXqtLWH1ipe9zVUaa0scR4o+HP/CSeINS1I3qwi88P3Gh+WYQ23zX3eZn POP7veuVm+BupY1LTLfxBDF4e1i7s77UYjYBrrzYI4UKxS7sKri3j+8rMnzbTyu2n+0F+1b4X/Z4 1fw1p2s2l3qNxq8u6VbNkH2G1DBXuZNxGVBYfKPmOGIHBr2i2uYry3ingkWWGVA6SIchlIyCD6EV f76lCM2rJ7fIm1KpJxvqt9e54l4h/ZpbWbzxFcQeJprGTUNSjurFktEJ061dg19aoc8rclpizHkG QY+4K9ttreO1gjhiQRxRqERFGAqgYA/KuA1/4rS+FdYNvqOjk2H25rI3ltciQx/6P5yyOhUEAkpH gZIZx2ya6zwfrz+KPC+lavJZyadJe20c72crh3gZlBKMRwSp4JHHFTUdWUU57fL+un9XKh7OMmo7 /wBf5/1Y2KKKK5jcKKKKACub+IGr+IND8M3F34Z0WPX9WR0CWMk4hDKWAY7j6DnFdJXnPxY+FzeP ms7tvF+teGIbCKQyDS5/LRwcEs/uAP1NdeFVN1o+1do+abXpZWeu2hw411lh5+wTcraWaT9U2mtN 9Uzm9O+IXxburdzefDi1tn3Y8v7crZGOuQfrWWsXitJDIvwg0FXJzuHlg1x+mX3gGaNLe3+M+s3D In3t7liBxknFXv8AijP+iva1/wB9P/hXs1qbp1JJU+W/Tlmvzdzw8PUVWlFurztdeam9fVK33HTe Z4x/6JJof/fUdct8QF8fLpUd1pfwD8L+I9QjkVBbXckKYjJ+YqxB6enen/8AFGf9Fe1r/vp/8K5b 4mXXw5t/CNymr/HzXvDdrM6RjUIZ2jkRt2QFYqeTjH0rOnH317v4T/RnS5X0Uvxh/keifs23nj6b xJq6eKvgtoPwzsfsiGK/0q6ikkuZN5/dFUXO0DnJPWrP7av/ACRg/wDYRg/k1cP+x/L8Pj401seE fjxrvxTvXsFMml6reebHBGJP9cqlRzkhcg9xXcftq/8AJGT/ANhGD+TV04KPLnFFWt70ejX/AKVd nJnF/wCw8Um9eSXZ9PJL8j2TTr2LTfCltdztthgskldvRVjBP6Cvm/4K+Dx8f/FurfEjxdD9r09b k2+madNzEFU5GV7qoI+XoW3E54x77q+ny6t8L7uyg5muNIaJB6sYcCvMP2Mtatr34QR6ch23mm3k 0VxERhlLNvUkfQ4/A1lhZSoYLEV6Xx3jG/VRd7/e0kTjoQxWZ4TDV9afLOVukpR5Ur97JtnusVvH bwrFEixxqMBEUBQPTArwz9or4K2mqaHdeL/DkA0zxVpQ+2CazGxrhU5OcfxgDKt14wcgmvd84rnP iLr1p4a8C69qV64S2t7KVmz3JUgKPckgfjXl4HEVsPiITo73Wnfyfe57OZ4XD4vCTp4j4Um7/wAt luuzRj/BP4gN8TvhppGuTBReSIYboKML5yHa5A9CRn8a+UbFv+GPP2ypLJj9l+HXxGO+LtFbXTPw OvG2V8f7s6dkr3j9jfS7jTfgrZyTqyi6u5541YY+TdtBHsdpNH7YnwOHxz+DOpafawh/EGm51HSm zgmZFO6PPYSIWT6kHtXp1fY4bMK2G/5dNuPpro/kzzcHKvjMqw2Kl/FUYy9XbX/wJHuNfM37dnxm ufh/8M4fCmgPI/i7xhJ/ZtnDbtiVYWIWV1wcgtuWNT/ekB7Gtr9j349xfFr4HwX2tXQi13w8hsdZ af5WBjXKzMMcbkAY+jBh2rxr9ne1uP2qv2nPEPxj1OJm8J+G3+weHYZR8rOAdjgeoRmkPH3plHVK 5cPhvYVpzrrSnv5vovn+R6NfEKtShCi9am3kur+X5n0n+zX8GbX4E/CPRvDMaxm/VPtOozxjAmun AMh+g4UeiqBXg/7S/wDyfJ+z1/22/wDQmr7Jr42/aX/5Pk/Z6/7bf+hNU4KpKriJzm7txn/6SzTF QjToRhFaJx/9KR9k1R13WrLw3ot9qupXKWmn2MD3NxPI2FjjRSzMT7AVer49/bw+IWp+Jbjw18D/ AAlJv8Q+LbiM3uw58q13fKr89GKs7A9Uicd64sNQeIqqnsur7LqzpxFb2FJz3fTzfRHl/wAN/hBd ftyeIPij8S/EXm2Wn3cUmk+FxIDiCRAfLcj+IRgjI6F5ZQegr2j9gX4sX2veB9S+G/iXfB4s8ETG xkhmbLtbBiqc99jK0ee4VT/FXq/w61P4cfB3wTpPgzT/ABTodtBo8ItWWTUIlkaQf6xn+b77NuJz 3NfMn7RV5a/BD48+Ffj94PurfVPDOpT/ANl+JP7NlWWNm2gMSVyMtGoPrvgjH8Ve37X6854a1o/Y 8rLRfNfieOqX1PkxF7y+3536/wDbr/A+6WtYZGLNEjHOcsoPOMZ/SnxxrGoVFCKOiqMAVX0vU7XW tNtb+ynW5s7qJZoZozlXRgCrA+hBq3XzfkfQhRRRSAKKKKACkZQ6lWAZSMEEZBpaKAPHfifp2reF 7zTx4O+F+jeJIpUc3EziKExMCMLg4zkEnPtWHb3njaS3jaT4RaLHIygsmY/lPcV77j2owPSvR+uX pxg4Jtdbyu/XW33JHlLAuNWVRVWk/s2jZenu3+9s8G+0eMv+iS6L/wCQ68/8feIvizHqaWmk/s4e H/ENhGgdri7uYI18w9lU5PA7nFfXO0elG0elTHFKLu6af/gX6M2eFb/5eP8A8l/yPnv9m/UPH934 k1dfFnwX0P4aWItEMWoaXcxPJcSbz+6KoM4A5zmr37ZttNdfBtkghknf+0IPljQsedwHT3IH417t j2pGUMMEZHvWlDG+xxcMUoL3WnZN9PN3ZjjMD9bwVTBufxpq9l18lYpaEjR6Lp6spVlt4wVIwQdo 4r568dfC7xf8J/H1147+G8X9oWV5l9S0HGdxJy21eNyk5bj5lJOMgkV9KUlThcbPCVJSik4y0aez X9bMWPy2lj6cYTbjKDvGS0cX3X6p6M+TfHn7U1n4u8D6r4bv/C/iLQ9avrYwDyF/1cnbk7WK56jG SM1yHw8h8bftERad4I1LVxY+H/DyxtfM24XUq5IXIbl3GCoJwF4JycV9utbxu4do1Zh0YqCa5zS/ ht4f0fxpqXiuz09Ydc1GMRXNwHbDKMfw5wCcDJHXAr3aOcYXD0ZwoUOSW8XfmtLbra2nrrbQ+XxH D2NxWIhUxWK9pD4ZK3JeG9nyt3963RaXV0bejaRaaBpVppthAttZWsSwwwp0VFGAKuGlor5Jtyd3 ufexiopRirJH5rftUfCnxh8J/jHreneAIbhdD+LMQsmtbaBmj+0NJ+9hJUfuwS5l3f3Wm7CvvD4K fC3T/gz8M9D8J6fh1sYf38+MG4nb5pZT7s5Jrt2QMQSASDkcdKdXoYjGzxFKFKS238+iv6LQ4aGD hQqyqJ77eXV29XqFfHv7SGn3dz+29+z5NDZ3M0Ki4LTRwO8abSSdzAYXAPcivsKmlAzBiASOhx0r nw9b2E3O19GvvTX6nRWpKtFRb6p/c7lPWtTXRdHvtQkilnS1gknaKFSzuFUttUDqTjgV8ffsS+Dt W+KXjjxZ8ffF1pNDqGszyWui29zGymC34DsobBACqkQ452Ow4evs6kVFjUBQAB2AxTp13SpThFay sr+XVfPQmpRVSpCcnpHW3n3+R80ah/wTr+CWpaleXsmgX8ct1cSXMixanMq75HLtgbuBuY8ds11N r+yB8PtB+Dfin4d6Dp0mn6XrzNcyzSzNNKt1tURzBnzgoUQjH92vcKSrljcTJJSqN2830EsLQTbU Fd76dz5U/YF8WeI7bwn4k+GniqwurfVPA179hS4khdYmhYsVjV2ABCkHbjP7toz3r6spoUKxIGCe vvTqyxFVV6sqiVr/ANP8S6FN0aapt3sFFFFc5uFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//Z --0000000000009b05070596b116c3-- From nobody Thu Nov 7 09:23:57 2019 Return-Path: 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 DD7F612093F for ; Thu, 7 Nov 2019 09:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 DGdKGfY2oIXw for ; Thu, 7 Nov 2019 09:23:53 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A191209C3 for ; Thu, 7 Nov 2019 09:23:53 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id c11so3142101iom.10 for ; Thu, 07 Nov 2019 09:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ShNK/t1sS3qCwQJfgKAsHxMbDjZ9eNSLPrNMZ50PGMc=; b=C6AeXZmblszcQZbP2aysant8AqAiIgyPLRpFe8aArGU6eTcQDp/NQ7QkIbYE/sTr+v N2/Vi964cqw+3SrRFGEr2yq/OCSSnWuhnrnNxtkWi9RuGzQq2qPDI7BJyhtiP21pAF6t RPD12BDBJZpy3NJKGlqTpMns6xBSQsvcIh6/g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ShNK/t1sS3qCwQJfgKAsHxMbDjZ9eNSLPrNMZ50PGMc=; b=qhAsrXzFZiqslMWXCBM+42rvVmdfAgIlKCqQxRH4/HGOn3eUVKmDY3wXj/wgxdNcmO /qUNQg2gGkAmsIWLV6P+8hZX8rXnrWPv8Gx+fYuqVBZ75biPtlzIQoUXgIDMc0P+07a+ 2TCfPmO26dCq0o9jfKlolXbDA1awYIhnB3x5Uhj5aRCgB4aN+fgzNINImpOoE+NJ2+/H IZK1Rv18NH6axROeCVSvhXWO7AiHhqSxaKmx+0tBF3O7SYPleZIg6AcXRNeGPTtuW1Bb UPDGGZgarXy/XCMRnzB8h7KP0rfAnFY0R0poA7+zGX85AINSiP51ZBqO30/kra+kxESg CwEA== X-Gm-Message-State: APjAAAWEiJ73qvt30X1sgqn67vbH1gtgX6ZVr2oLR9aAJzxR+KVATYUB Mkt58092lBrv97pqj6SYS33XMfpa0AEi8bPVpyn2ZA== X-Google-Smtp-Source: APXvYqxMv1e708/3aSPgimpXBy17EPCgtHQFqE51FofUWInpNkDugCG9PhXnE8CiZg7Ycjz/6k/KVtvR00fbxly34sc= X-Received: by 2002:a05:6638:73a:: with SMTP id j26mr5243473jad.116.1573147432362; Thu, 07 Nov 2019 09:23:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 7 Nov 2019 09:23:37 -0800 Message-ID: To: "Weist, Bill" Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/related; boundary="000000000000e2e0d30596c4ed68" Archived-At: Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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, 07 Nov 2019 17:23:56 -0000 --000000000000e2e0d30596c4ed68 Content-Type: multipart/alternative; boundary="000000000000e2e0d00596c4ed67" --000000000000e2e0d00596c4ed67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Both of the cases you cited are entirely covered by ARC. If you are seeing failures, I would be pointing the finger toward said "intermediary SMTP system" which is modifying the message without properly affixing its own ARC set. --Kurt On Thu, Nov 7, 2019 at 8:45 AM Weist, Bill wrote: > Thank you both for replying. There are two instances where I have > identified ARC signatures consistently failing: > > > > Case 1: An intermediary SMTP system receives an email on behalf of a > recipient system whereby the =E2=80=9Cfrom=E2=80=9D field is required to = be changed for the > email to reply as desired by the recipient system. (example: > William.Weist@gmail.com rewritten to William.Weist@iqvia.com) > > > > Case 2: An Intermediary SMTP system receives an email on behalf of the > recipient system whereby the =E2=80=9Csubject=E2=80=9D field is required = to by changed for > the email to be categorized as desired by the recipient system. (example: > =E2=80=9CRE: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D modified t= o: =E2=80=9CRFC > Correspondence: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D) > > > > As Kurt pointed out below, the ARC signature is NOT intended to be > validated by hops >1 step away. However, I did not think this was the ca= se > and that ARC was specifically supposed to validate each custodian where > DKIM would be broken by the cases listed above. > > > > As differentiated from DKIM, the RFC reads as if ARC is designed to > validate the =E2=80=9Ccustodian=E2=80=9D and NOT the =E2=80=9Csender=E2= =80=9D therefore, =E2=80=9CFrom=E2=80=9D and > =E2=80=9CSubject=E2=80=9D would not be as desirable as say =E2=80=9CX-Rec= eived=E2=80=9D, > =E2=80=9CX-Google-Smtp-Source=E2=80=9D, and =E2=80=9CX-Gm-Message-State= =E2=80=9D in the case of Brandon=E2=80=99s > email to which I am replying. > > > > It is my suggestion that for ARC to be a valuable addition to DKIM, it > needs to focus on the =E2=80=9Ccustodian=E2=80=9D and not the =E2=80=9Cse= nder=E2=80=9D. > > > > Thank you both for your time and attention. > > -Bill > > > > *From:* Brandon Long > *Sent:* Wednesday, November 6, 2019 12:43 PM > *To:* Kurt Andersen (b) > *Cc:* Weist, Bill ; dmarc@ietf.org > *Subject:* Re: [dmarc-ietf] Question regarding RFC 8617 > > > > This email originated from outside of the organization. > > > > What's more, the point of including Subject and other mutable headers is > the same as it is for DKIM, those are the headers which are important to > the receiver, so they should be validated. > > As Kurt points out, the point of ARC is to acknowledge these changes hop > to hop, and the Arc Seal proves who did the change, the question becomes = do > you believe > > the person who changed it wasn't malicious. > > > > Brandon > > > > On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) wrote= : > > The choice of which headers are included in the signed set is strictly up > to the domain administrators who implement the signing practices. Also, t= he > AMS is only relevant for the next receiver, it is not intended to be > validated by hops >1 step away from the domain which adds that instance s= o > I don't see how mutability would matter. > > > > --Kurt Andersen > > > > On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill > wrote: > > DOI: 10.17487/RFC8617 > > > > The inclusion of the address headers in the signature, and possibly the > Subject, is an issue: > > > > ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D > microsoft.com > ; > s=3Darcselector9901; h=3DFrom:Date:Subject:Message-ID:Content-Type:MIME-V= ersion:X-MS-Exchange-SenderADCheck; > bh=3D; > > > > If a downstream server needs to modify either of these two values, the > signature check fails. > > > > It is my understanding that the Authenticated Received Check signature is > to validate the chain of possession. As such, in my opinion, the signatu= re > should only include immutable references. > > > > In my opinion, there is value in NOT requiring headers to be stripped by > downstream servers, thus maintaining the custody chain from origination t= o > destination. > > > > Thank you for your time and attention, > > > > *William M. Weist* > > *Enterprise Architect I =E2=80=93 Global Messaging =E2=80=93 Mobile and P= resence* > > CIO Team =E2=80=93 End User Computing > > *[image: IQVIA logo_96dpi_100pxheight]* > > Learn more > > about IQVIA=E2=84=A2 > > > > 400 Campus Drive > > Collegeville, PA 19426 > > USA > > > > O: +1 610 244 2646 <(610)%20244-2646> | M: +1 484 904 8244 > <(484)%20904-8244> > > > > > > ________________________________________ > *IMPORTANT* - PLEASE READ: This electronic message, including its > attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY > PRIVILEGED or PROTECTED information and is intended for the authorized > recipient of the sender. If you are not the intended recipient, you are > hereby notified that any use, disclosure, copying, or distribution of thi= s > message or any of the information included in it is unauthorized and > strictly prohibited. If you have received this message in error, please > immediately notify the sender by reply e-mail and permanently delete this > message and its attachments, along with any copies thereof, from all > locations received (e.g., computer, mobile device, etc.). To the extent > permitted by law, we may monitor electronic communications for the purpos= es > of ensuring compliance with our legal and regulatory obligations and > internal policies. We may also collect email traffic headers for analyzin= g > patterns of network traffic and managing client relationships. For furthe= r > information see: https://www.iqvia.com/about-us/privacy/privacy-policy > .. > Thank you. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > --000000000000e2e0d00596c4ed67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Both of the cases you cited are entirely covered by ARC. I= f you are seeing failures, I would be pointing the finger toward said "= ;intermediary SMTP system" which is modifying the message without prop= erly affixing its own ARC set.

--Kurt

On Thu, Nov 7= , 2019 at 8:45 AM Weist, Bill <William.Weist@iqvia.com> wrote:

Thank you both for replying.=C2=A0 There are two ins= tances where I have identified ARC signatures consistently failing:<= u>

=C2=A0

Case 1:=C2=A0 An intermediary SMTP system receives a= n email on behalf of a recipient system whereby the =E2=80=9Cfrom=E2=80=9D = field is required to be changed for the email to reply as desired by the re= cipient system.=C2=A0 (example: William.Weist@gmail.com rewritten to William.We= ist@iqvia.com)

=C2=A0

Case 2: An Intermediary SMTP system receives an emai= l on behalf of the recipient system whereby the =E2=80=9Csubject=E2=80=9D f= ield is required to by changed for the email to be categorized as desired b= y the recipient system. (example: =E2=80=9CRE: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D modified to:=C2=A0 =E2=80=9CRFC Corre= spondence: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D)=

=C2=A0

As Kurt pointed out below, the ARC signature is NOT = intended to be validated by hops >1 step away.=C2=A0 However, I did not = think this was the case and that ARC was specifically supposed to validate = each custodian where DKIM would be broken by the cases listed above.

=C2=A0

As differentiated from DKIM, the RFC reads as if ARC= is designed to validate the =E2=80=9Ccustodian=E2=80=9D and NOT the =E2=80= =9Csender=E2=80=9D therefore, =E2=80=9CFrom=E2=80=9D and =E2=80=9CSubject= =E2=80=9D would not be as desirable as say =E2=80=9CX-Received=E2=80=9D, = =E2=80=9CX-Google-Smtp-Source=E2=80=9D, and =E2=80=9CX-Gm-Message-State=E2= =80=9D in the case of Brandon=E2=80=99s email to which I am replying.

=C2=A0

It is my suggestion that for ARC to be a valuable ad= dition to DKIM, it needs to focus on the =E2=80=9Ccustodian=E2=80=9D and no= t the =E2=80=9Csender=E2=80=9D.

=C2=A0

Thank you both for your time and attention.

-Bill

=C2=A0

From: Brandon Long <blong@google.com>
Sent: Wednesday, November 6, 2019 12:43 PM
To: Kurt Andersen (b) <kboth@drkurt.com>
Cc: Weist, Bill <William.Weist@iqvia.com>; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Question regarding RFC 8617<= /p>

=C2=A0

This email originated from outside of the organ= ization.

=C2=A0

What's more, the point of including Subject and = other mutable headers is the same as it is for DKIM, those are the headers = which are important to the receiver, so they should be validated.=C2=A0=C2= =A0

As Kurt points out, the point of ARC is to acknowledge these changes hop to= hop, and the Arc Seal proves who did the change, the question=C2=A0becomes= do you believe

the person who changed it wasn't malicious.

=C2=A0

Brandon

=C2=A0

On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) <= ;kboth@drkurt.com= > wrote:

The choice of which headers are included in the sign= ed set is strictly up to the domain administrators who implement the signin= g practices. Also, the AMS is only relevant for the next receiver, it is no= t intended to be validated by hops >1 step away from the domain which adds that instance so I don't se= e how mutability would matter.

=C2=A0

--Kurt Andersen

=C2=A0

On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill <William.Weist@iqvia= .com> wrote:

DOI:=C2=A0 10.17487/RFC8617

=C2=A0

The inclusion of the address headers in the signatur= e, and possibly the Subject, is an issue:

=C2=A0

ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Dre= laxed/relaxed; d=3Dmicrosoft.com; s=3Darcselector9901; h=3DFrom:Dat= e:Subject:Message-ID:Content-Type:= MIME-Version:X-MS-Exchange-SenderADCheck; bh=3D;

=C2=A0

If a downstream server needs to modify either of the= se two values, the signature check fails.

=C2=A0

It is my understanding that the Authenticated Receiv= ed Check signature is to validate the chain of possession.=C2=A0 As such, i= n my opinion, the signature should only include immutable references.

=C2=A0

In my opinion, there is value in NOT requiring heade= rs to be stripped by downstream servers, thus maintaining the custody chain= from origination to destination.

=C2=A0

Thank you for your time and attention,=

=C2=A0

William M. Weist

Enterprise Archite= ct I =E2=80=93 Global Messaging =E2=80=93 Mobile and Presence=

CIO Team =E2=80=93 En= d User Computing

3D"IQVIA

Learn more about IQVIA=E2=84=A2

=C2=A0

400 Campus Drive

Collegeville, PA 19426=

USA

=C2=A0

O: +1 610 244 2646 | M:= +1 484 904 8244

=C2=A0



________________________________________
IMPORTANT - PLEASE READ: This = electronic message, including its attachments, is CONFIDENTIAL and may cont= ain PROPRIETARY or LEGALLY PRIVILEGED or PROTECTED information and is intended for the authorized recipient of the sender. If= you are not the intended recipient, you are hereby notified that any use, = disclosure, copying, or distribution of this message or any of the informat= ion included in it is unauthorized and strictly prohibited. If you have received this message in error, pleas= e immediately notify the sender by reply e-mail and permanently delete this= message and its attachments, along with any copies thereof, from all locat= ions received (e.g., computer, mobile device, etc.). To the extent permitted by law, we may monitor electronic c= ommunications for the purposes of ensuring compliance with our legal and re= gulatory obligations and internal policies. We may also collect email traff= ic headers for analyzing patterns of network traffic and managing client relationships. For further informat= ion see: https://www.iqvia.com/about-us/privacy/privacy-policy.. Thank you.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.i= etf.org/mailman/listinfo/dmarc

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://w= ww.ietf.org/mailman/listinfo/dmarc

--000000000000e2e0d00596c4ed67-- --000000000000e2e0d30596c4ed68 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <16e46e3360d4ce8e91> X-Attachment-Id: 16e46e3360d4ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABkANUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKo65qB0jRr++CeabW3knCE43bVLYz74ry/wn8dp9e+I2k+HLzQhYafqnh+11W31QXQdTdSo0j2 hXAwVjQuGz8wDcDHOkacppuPQzlUjFpPqevUV8/2v7Tl3qOj398NAttJtj4lTQ7DUNUvtlobZ4PO jvbhwv7pJB8qLzlnjBI3cekeIPHV/wCEfhXqHinVrSxN3Y2j3UsNreF7Zgp+8spUfKV+bJHFaSoV INKS3IjWhO9nsdxRXnd18a/D8fjKy0e31TS7uxfSrzVLvUIb9HW1WB4V+YLnAPmnkkY2981tR/E7 w1NpMupJqe+2inFtIqwSmZJSu4IYtu8Er8wG3kc9KzdOas2i1Ug20nsdVRXl/if456T4XuJr+aSO 88NrpEGpR3lkGleRpbjyVCgcFeh/OrVn8adDXxvqWhahqNnZBfsJsGferzC5QlN+RhNzqVXOMkY6 1XsZ2vb+v6Ye0he1z0aivK/jN8ZLj4X32i2lvp1teT6lFcPbpdXPlNeTRBCtlbqAS9xKGYouMYjb JrqvG/j+08EeDbzX5oJL0wmOCOytmUyzXMkixRwAk7QzSOqckAE80vZTtF2+LYPaRV79NzqqK81h +IHijw3rWg2vjHRNOs7PWpDaxXmkXklwtpciN5BFNvjXKlY3AkHG4AEDIrY1j4naJa+Gzqdhqum3 Hm6b/ats1zcmKGW2yo84uFbCfOvzYP3hQ6U7pW3Eqke52VFci3xX8JL4hl0I69af2vFM1tJaBiWW ZYhMYjxjzPLO8J94ryARXJyfHux1jwTceIvDwtriFdJ1K/jh1B3hmaS1AIUR7fmQ5+ZgRtyvBzwK lN9AdSEd2etUVytn8R9Ck1Gy0q41GGLV51jBtgGwsjxh1jLY2hypyFJ3Ec4q94c8a6L4skuU0i/j vjbkeYY1YDBJAZSQAykqRuXI4PPFS4yWrRfNF9TcorkZfix4St4dUmn1y2tYNLiae7luN0SRRK21 pNzAAoG4LDIB6mlHxV8KG4sof7ahEl4I2i3I4GHYrGWJGE3sCF3Y3ds0ezn2Fzx7nW0Vy3iz4n+F vA90ltr2uWmmXDW7XYjmY7vJVgrykAHCKWXcx4XIyRTr74meF9N16HRbnW7WHUpWiRYSxIDSf6pW YDarP/CpILds0ck7XsHPHa509FczD8SvC89xY26a7Yme+gubm2i80B5Yrdglw4B5xGxAb0JxW7pu o22r6fa31nMtxaXUSzQzJ910YAqw9iCDScWt0VdPYs0UUVIwooooAKKKKAKOt6edX0e/sQ/lG6t5 IPMxnbuUrnHfGa8l1f8AZ2OreHJ9OHiO4sLo2OlWltqFnCFmtns1dHkXJP8ArY5HQjsGPNeyTTJb wvLIwSNFLMzdAAMk15pa/tKfDi9mMdv4nt5nAzhY5DwO/wB2uyhDESTlRi2lvZXt6nHXq4anKMa8 0m9ru1/QlX4Y6noLa8/h3UdNgi1O9gn+wajp5ntxbx2kdv8AZ8K6nH7oPu/DBqHSvgsul/BW68Aj U1b7VHcK9wtsFhiM0rSskUO4hIl3FUjydqgDJxVz/hf/AID/AOhgi/79Sf8AxNcv4i/bM+DnhLUf sGseOLPTrsoJBFPFKpZT/EPl5H0q1DFS91Qb26dvkJSw17qS69e+5ufET4G6f48vFkjuI9IiGl3N gVtrVQS8ksEiSEjGQrQfd7hjyKz2+C2rtbidNZsrLUpNSjvL1bO3nSG/hSFo1hnYzGVgpbzAQ4GV VSCuQdP4X/tJfDX4zaxd6V4N8WWWu6jawfapbaDcHWLdt34YDI3YH4itf4ufFC0+EfhI69e2U9/C J44BDbkBstnnJ44ANOEMVKpHDKL5nok139Sa1TDUaU8TUlaMdW+1vQ4+z/Z9nsfB76NDr6iddF/s uK6Nn8qyC5a4SUpv5XJAKZ6DrW7rPwnuvEFvr7XeqQpeaxJpk0zw2pCI9o6OdoLE4Yrxk/LnvXoV ndLe2cFwgISVFkAbrgjI/nXN/ED4neHfhjpYvtf1BbVX4ihQF5piOoRBycdz0HesoOvWqKEFeTey Wt/6RpUlQw9J1KslGKWrbsrHJ/E/4K3Pj7X7rULfV4bRL7To9Nm+02zSy2XlytIlzZuHXyZgXJ3c 5KRn+DBuad8F4F+D6eAtR1KSdIV/dataxLDc+akvmxXTZ3KbgSBZGbGGcE7QDivPP+Gyba63T6f4 E8Q32nA/8fSIMY9eAR+tehfC/wDaD8JfFaX7Lp11JZaqF3HT75dkpA67Tkq+O+Dkd69Otl+Y4elz VKbUY69Hb1tt8zxsPm+U4qt7OlVTlLbdX9L2v8jP1D4X+NvEHiXw5e634w0u/wBM0WZp1sYdGeE3 ErRtF5rsJyN6pI+0AbQzbsHAxk2v7PerN4dbRr7xRBNbW/h5/Ddk8Wn7HWHzY3SaQ7zuk2xqpA2q TyAM4r2LxBqw0HQ9Q1I2812LO3kuPs9uMySbFLbVHcnGBXn/AOzv8fdF/aK+H8fibSLWfTJFma3u 9Nu3RprWQYIDFSQQylWBHUNXnKdZwdSPwq3Redv1PZdOip8r3d+r8v8AgF64+FZmu5JxqKqX8Tx+ IseR/diWPys577Pve+MVg/8ACjb+40GTSrrX4Xjj0/WNMtZY7Iqyw3rKVLguQzx7cEjAb0FewU2R 1jVmZgqqMlmOAB61gq01szZ0oPdHkNr8Bfsni6e/+2WV5pN3qVvrFxa3trJJItzFDHGpjIlCAboY 3DMjMpBAOCNu/wDDX4caj4J1HV57jV4pLO7VEh0uwgaG0gZWctMkbu+x33gMqkJ8gIUEnOD8Cf2k tG+P2s+MrbQtKv4NP8PXi2iapOUa3vwd3zxlSSB8ucNztZW6NVj4gftCaZ8PfjL4D+Hl1pN9d3vi 0SmG+gZBDbbOm8E7juII+UHHeumUcQ5OjJa2202Sv+XzMIOgoqrF6N7+r/zMCP8AZx1G7+1HVfFP 9pTSaXcaWbqa2Z5bhZbiKbzZS0hG791t2oFT5jgdAOg8TfBP+3PGmpasl1ZyafrEtrLqFnf28s3z QBQvl7ZVXkKv31baRuHpXqtLWH1ipe9zVUaa0scR4o+HP/CSeINS1I3qwi88P3Gh+WYQ23zX3eZn POP7veuVm+BupY1LTLfxBDF4e1i7s77UYjYBrrzYI4UKxS7sKri3j+8rMnzbTyu2n+0F+1b4X/Z4 1fw1p2s2l3qNxq8u6VbNkH2G1DBXuZNxGVBYfKPmOGIHBr2i2uYry3ingkWWGVA6SIchlIyCD6EV f76lCM2rJ7fIm1KpJxvqt9e54l4h/ZpbWbzxFcQeJprGTUNSjurFktEJ061dg19aoc8rclpizHkG QY+4K9ttreO1gjhiQRxRqERFGAqgYA/KuA1/4rS+FdYNvqOjk2H25rI3ltciQx/6P5yyOhUEAkpH gZIZx2ya6zwfrz+KPC+lavJZyadJe20c72crh3gZlBKMRwSp4JHHFTUdWUU57fL+un9XKh7OMmo7 /wBf5/1Y2KKKK5jcKKKKACub+IGr+IND8M3F34Z0WPX9WR0CWMk4hDKWAY7j6DnFdJXnPxY+FzeP ms7tvF+teGIbCKQyDS5/LRwcEs/uAP1NdeFVN1o+1do+abXpZWeu2hw411lh5+wTcraWaT9U2mtN 9Uzm9O+IXxburdzefDi1tn3Y8v7crZGOuQfrWWsXitJDIvwg0FXJzuHlg1x+mX3gGaNLe3+M+s3D In3t7liBxknFXv8AijP+iva1/wB9P/hXs1qbp1JJU+W/Tlmvzdzw8PUVWlFurztdeam9fVK33HTe Z4x/6JJof/fUdct8QF8fLpUd1pfwD8L+I9QjkVBbXckKYjJ+YqxB6enen/8AFGf9Fe1r/vp/8K5b 4mXXw5t/CNymr/HzXvDdrM6RjUIZ2jkRt2QFYqeTjH0rOnH317v4T/RnS5X0Uvxh/keifs23nj6b xJq6eKvgtoPwzsfsiGK/0q6ikkuZN5/dFUXO0DnJPWrP7av/ACRg/wDYRg/k1cP+x/L8Pj401seE fjxrvxTvXsFMml6reebHBGJP9cqlRzkhcg9xXcftq/8AJGT/ANhGD+TV04KPLnFFWt70ejX/AKVd nJnF/wCw8Um9eSXZ9PJL8j2TTr2LTfCltdztthgskldvRVjBP6Cvm/4K+Dx8f/FurfEjxdD9r09b k2+madNzEFU5GV7qoI+XoW3E54x77q+ny6t8L7uyg5muNIaJB6sYcCvMP2Mtatr34QR6ch23mm3k 0VxERhlLNvUkfQ4/A1lhZSoYLEV6Xx3jG/VRd7/e0kTjoQxWZ4TDV9afLOVukpR5Ur97JtnusVvH bwrFEixxqMBEUBQPTArwz9or4K2mqaHdeL/DkA0zxVpQ+2CazGxrhU5OcfxgDKt14wcgmvd84rnP iLr1p4a8C69qV64S2t7KVmz3JUgKPckgfjXl4HEVsPiITo73Wnfyfe57OZ4XD4vCTp4j4Um7/wAt luuzRj/BP4gN8TvhppGuTBReSIYboKML5yHa5A9CRn8a+UbFv+GPP2ypLJj9l+HXxGO+LtFbXTPw OvG2V8f7s6dkr3j9jfS7jTfgrZyTqyi6u5541YY+TdtBHsdpNH7YnwOHxz+DOpafawh/EGm51HSm zgmZFO6PPYSIWT6kHtXp1fY4bMK2G/5dNuPpro/kzzcHKvjMqw2Kl/FUYy9XbX/wJHuNfM37dnxm ufh/8M4fCmgPI/i7xhJ/ZtnDbtiVYWIWV1wcgtuWNT/ekB7Gtr9j349xfFr4HwX2tXQi13w8hsdZ af5WBjXKzMMcbkAY+jBh2rxr9ne1uP2qv2nPEPxj1OJm8J+G3+weHYZR8rOAdjgeoRmkPH3plHVK 5cPhvYVpzrrSnv5vovn+R6NfEKtShCi9am3kur+X5n0n+zX8GbX4E/CPRvDMaxm/VPtOozxjAmun AMh+g4UeiqBXg/7S/wDyfJ+z1/22/wDQmr7Jr42/aX/5Pk/Z6/7bf+hNU4KpKriJzm7txn/6SzTF QjToRhFaJx/9KR9k1R13WrLw3ot9qupXKWmn2MD3NxPI2FjjRSzMT7AVer49/bw+IWp+Jbjw18D/ AAlJv8Q+LbiM3uw58q13fKr89GKs7A9Uicd64sNQeIqqnsur7LqzpxFb2FJz3fTzfRHl/wAN/hBd ftyeIPij8S/EXm2Wn3cUmk+FxIDiCRAfLcj+IRgjI6F5ZQegr2j9gX4sX2veB9S+G/iXfB4s8ETG xkhmbLtbBiqc99jK0ee4VT/FXq/w61P4cfB3wTpPgzT/ABTodtBo8ItWWTUIlkaQf6xn+b77NuJz 3NfMn7RV5a/BD48+Ffj94PurfVPDOpT/ANl+JP7NlWWNm2gMSVyMtGoPrvgjH8Ve37X6854a1o/Y 8rLRfNfieOqX1PkxF7y+3536/wDbr/A+6WtYZGLNEjHOcsoPOMZ/SnxxrGoVFCKOiqMAVX0vU7XW tNtb+ynW5s7qJZoZozlXRgCrA+hBq3XzfkfQhRRRSAKKKKACkZQ6lWAZSMEEZBpaKAPHfifp2reF 7zTx4O+F+jeJIpUc3EziKExMCMLg4zkEnPtWHb3njaS3jaT4RaLHIygsmY/lPcV77j2owPSvR+uX pxg4Jtdbyu/XW33JHlLAuNWVRVWk/s2jZenu3+9s8G+0eMv+iS6L/wCQ68/8feIvizHqaWmk/s4e H/ENhGgdri7uYI18w9lU5PA7nFfXO0elG0elTHFKLu6af/gX6M2eFb/5eP8A8l/yPnv9m/UPH934 k1dfFnwX0P4aWItEMWoaXcxPJcSbz+6KoM4A5zmr37ZttNdfBtkghknf+0IPljQsedwHT3IH417t j2pGUMMEZHvWlDG+xxcMUoL3WnZN9PN3ZjjMD9bwVTBufxpq9l18lYpaEjR6Lp6spVlt4wVIwQdo 4r568dfC7xf8J/H1147+G8X9oWV5l9S0HGdxJy21eNyk5bj5lJOMgkV9KUlThcbPCVJSik4y0aez X9bMWPy2lj6cYTbjKDvGS0cX3X6p6M+TfHn7U1n4u8D6r4bv/C/iLQ9avrYwDyF/1cnbk7WK56jG SM1yHw8h8bftERad4I1LVxY+H/DyxtfM24XUq5IXIbl3GCoJwF4JycV9utbxu4do1Zh0YqCa5zS/ ht4f0fxpqXiuz09Ydc1GMRXNwHbDKMfw5wCcDJHXAr3aOcYXD0ZwoUOSW8XfmtLbra2nrrbQ+XxH D2NxWIhUxWK9pD4ZK3JeG9nyt3963RaXV0bejaRaaBpVppthAttZWsSwwwp0VFGAKuGlor5Jtyd3 ufexiopRirJH5rftUfCnxh8J/jHreneAIbhdD+LMQsmtbaBmj+0NJ+9hJUfuwS5l3f3Wm7CvvD4K fC3T/gz8M9D8J6fh1sYf38+MG4nb5pZT7s5Jrt2QMQSASDkcdKdXoYjGzxFKFKS238+iv6LQ4aGD hQqyqJ77eXV29XqFfHv7SGn3dz+29+z5NDZ3M0Ki4LTRwO8abSSdzAYXAPcivsKmlAzBiASOhx0r nw9b2E3O19GvvTX6nRWpKtFRb6p/c7lPWtTXRdHvtQkilnS1gknaKFSzuFUttUDqTjgV8ffsS+Dt W+KXjjxZ8ffF1pNDqGszyWui29zGymC34DsobBACqkQ452Ow4evs6kVFjUBQAB2AxTp13SpThFay sr+XVfPQmpRVSpCcnpHW3n3+R80ah/wTr+CWpaleXsmgX8ct1cSXMixanMq75HLtgbuBuY8ds11N r+yB8PtB+Dfin4d6Dp0mn6XrzNcyzSzNNKt1tURzBnzgoUQjH92vcKSrljcTJJSqN2830EsLQTbU Fd76dz5U/YF8WeI7bwn4k+GniqwurfVPA179hS4khdYmhYsVjV2ABCkHbjP7toz3r6spoUKxIGCe vvTqyxFVV6sqiVr/ANP8S6FN0aapt3sFFFFc5uFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//Z --000000000000e2e0d30596c4ed68-- From nobody Thu Nov 7 09:28:31 2019 Return-Path: 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 48127120977 for ; Thu, 7 Nov 2019 09:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 HFqTJYfaXwFg for ; Thu, 7 Nov 2019 09:28:28 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C80912097C for ; Thu, 7 Nov 2019 09:28:28 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id 94so2694392oty.8 for ; Thu, 07 Nov 2019 09:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Db4aXyXqy+JEi2go1c/6O1Y2ewCHXZuFTzQE03+TFsY=; b=CKypHuHv3A02aLV+XGfWeAb8kr2IEn74cMyyShD5Ye6Bfo6zheKzeZVJFQygNFOOqQ C71GwAHwfUJqOfaBjcLYSLOdIpkC5P2JuaNXRptFShN0jsM0BUU7sRc4KJQt4REta1TT gEUMpPD3fj1+GSAofuqVud06ogQ9LtoJmw6zdxBqoAabKtT2f/+aOcA31RZNqW3uGV3F 7BfCcwwlnnjWwUTNyWVmnMoEQh8HakeTIysUdnikiCeP1ibgEnT6VoJLB74gw8WBMGXN V+zQBJmyzfe1Nk7EGBN0Z3oMx6Rj0pSPnvZFRb9OmHceTj3GFGsxC/eW5mxS6d5Dql7H mMaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Db4aXyXqy+JEi2go1c/6O1Y2ewCHXZuFTzQE03+TFsY=; b=Nv10WTIA9S0NKRmXZa4uTLhbfyDH1qj+X+cKSoOtIF2ggjLddl6kY15GlBMRnYXBiK K5ONZs0kLCjp8aEeZHGfmBz01XRIABnsZgMtt0yUXMKhBH71Tbz+FciXwiuOkZyC8Onn SO9uRgPwPQja5PWeXxWA4+ed3htnvnqlHhRGR8+fXKLknrDZm13nKibY7w0JCZrnMzT8 FdRf62SjI1b/P5zr/0Y8ajY5DA5RakUcktlcLE/UbV4cLyC9aPZVuIQR59WMrD5tfPeF xGlirfYebDEIvULB/Nbuh3JmCg91qcOA6az6xZ2Ak3kXBOuE7jBnmCSk4/wcppkmdYR3 UN8g== X-Gm-Message-State: APjAAAW0MjycSdn+UhpfJqxh5I4dbJ0mFXOBUd6gAWONrL4aAm4Bw5nM yKK/KOSURl+sVQO5LZP0Aco= X-Google-Smtp-Source: APXvYqyWIqlS6CICyhOK44MxSlKy/0vSjiGJQsduoWPAoFUTLNz03f9n8rS7c8yiQXf937wTf1fxVg== X-Received: by 2002:a05:6830:1611:: with SMTP id g17mr4030861otr.29.1573147707693; Thu, 07 Nov 2019 09:28:27 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:911f:9579:419e:7fa6? ([2600:1700:a3a0:4c80:911f:9579:419e:7fa6]) by smtp.gmail.com with ESMTPSA id w26sm929037otm.28.2019.11.07.09.28.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 09:28:26 -0800 (PST) To: Brandon Long , "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Weist, Bill" References: From: Dave Crocker Message-ID: <2b25082c-34b2-93f6-9412-6b669652e317@gmail.com> Date: Thu, 7 Nov 2019 09:28:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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, 07 Nov 2019 17:28:30 -0000 On 11/6/2019 9:43 AM, Brandon Long wrote: > What's more, the point of including Subject and other mutable headers is > the same as it is for DKIM, those are the headers which are important to > the receiver, so they should be validated. This being a technical list, I'm going to get picky and note that DKIM does not 'validate' those fields. There is a derivative data integrity benefit, between signing and validated, for such fields, but that is quite different from any claim that the contents of those fields are 'valid'. Some signing sites have much more stringent uses of DKIM than are provided by the standard. That's fine, of course, but it has nothing to do with the standard. Hence any receive-side reliance on such signer data validation is outside the DKIM standard. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Nov 7 11:11:19 2019 Return-Path: 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 A5CB5120113 for ; Thu, 7 Nov 2019 08:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no 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 yGLY-ekqZBYW for ; Thu, 7 Nov 2019 08:45:42 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820099.outbound.protection.outlook.com [40.107.82.99]) (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 C6D55120858 for ; Thu, 7 Nov 2019 08:45:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fNA3fRGujb7X7YuRGtjn+TgeZ9U88/t7Ohw5NmH7oCk0LB4lWs3sTsV0ye7VEkNer2aKRshIAE+wws9wXP2jH9xVgAbmMEikLOs3n8GJqj99R2FE6vCSGm+ONYicYC5QMOLTojP/OyN/H8xj4awbgwL/fHh+GFIVgpBwFehxp8EwnsDCmSaL1E/Bt5cO+bS5uF+JWSRH07T+SIKPjxYEBjEBb4hkZ5jEWR337Ki/6dlwY1uBzloHD1z0EBjeyaNjdTWdz/cxyMasSI40jLxHbiH7Jg7FrmhgGxIm2sRg7zkUNk3EOREoLWQjR4qoOsNMfhwtSl7aovsMDUCuKg2dvQ== 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=n8oLzf9OSL+h4dCj3b9vsCWwAGz113OkbPINPXENWYc=; b=Z2v0oRlTn8hcUf3mnYWItJ6BGx4/dlxrLnhLYFySigpSMLY0a2UJ0+MLObhQ1soXI0iNzQIVDbrRv4Tw2TfGF1VZGTt9BgyLQLUJApTYwyjOOcrKBDa2h3vImwfNSw14bAjRFg2fK39J+UpkDVNllbEYfpffW+RDFqfUxE0AWZtWTz7h8xP6Evh/5OkSFql3/vBZYj+gXdYTrZc2HZYmkta0beCELb5coOGjWf1Nj2CIEXP6yhDls2OsUi3S3y4dwEqTejy92QqULIol0ZlFsXWC49vFV4gSlDRl+MQqCZ+CUextFlOxqfQxpJYGqb5rV7HfiqswpLFnQEaxHr6eFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iqvia.com; dmarc=pass action=none header.from=iqvia.com; dkim=pass header.d=iqvia.com; arc=none Received: from BYAPR05MB4167.namprd05.prod.outlook.com (52.135.200.138) by BYAPR05MB4855.namprd05.prod.outlook.com (52.135.232.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Thu, 7 Nov 2019 16:45:38 +0000 Received: from BYAPR05MB4167.namprd05.prod.outlook.com ([fe80::59e3:2661:ff12:f7be]) by BYAPR05MB4167.namprd05.prod.outlook.com ([fe80::59e3:2661:ff12:f7be%3]) with mapi id 15.20.2430.014; Thu, 7 Nov 2019 16:45:38 +0000 From: "Weist, Bill" To: Brandon Long , "Kurt Andersen (b)" CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Question regarding RFC 8617 Thread-Index: AdWTMguQWnkvj8CtSAGz9qIfZtaWOQBhe5aAAARtOwAAL3EZ4A== Date: Thu, 7 Nov 2019 16:45:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.700.9 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=William.Weist@iqvia.com; x-originating-ip: [192.69.82.131] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d05a6e83-65a4-47cd-4680-08d763a1eb1a x-ms-traffictypediagnostic: BYAPR05MB4855: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(39860400002)(396003)(376002)(346002)(136003)(51744003)(189003)(199004)(33656002)(76176011)(476003)(478600001)(11346002)(14454004)(2906002)(966005)(8676002)(45080400002)(81156014)(3846002)(102836004)(26005)(53546011)(7736002)(6116002)(6246003)(81166006)(8936002)(76116006)(66556008)(236005)(9686003)(790700001)(66946007)(486006)(66446008)(64756008)(66476007)(110136005)(7696005)(99286004)(316002)(446003)(186003)(4326008)(6506007)(5660300002)(25786009)(71200400001)(86362001)(54896002)(733005)(6306002)(55016002)(66616009)(6436002)(71190400001)(229853002)(5024004)(99936001)(256004)(606006)(5070765005)(66066001)(74316002)(52536014)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4855; H:BYAPR05MB4167.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:3; received-spf: None (protection.outlook.com: iqvia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PLdv/v+rKfl5Sajx/aGG12BTZVTZth+vDfCG6QqYXd3M98BCDaKy5LIQ58IWe/fG8wjVPfuPmybpiv7HRqCknCwd8310k0SCP0rpb1wL8ONhqlzvipdxNtrBQGtPjGkVBpfJ8yz/8Cc0nSVynFhjsDrX8626pZOmaI1pjU3vMozilfjrmnt0zY0aS9sl1ptEKoo1T2IJ+GwaWL1zIVDl4RZudHz6fyTAsY2OgU+LEePeVYL025RAfPeK5OByKByCqFIP398lx4S1tNY6dHBA5w367qtQHR3Uxni6zvzpxg8O1slBYbTGzga4TjrX2Y/RXmSaoqJyp99lrpF81VLsMQCeBf+libWpPbGjq9/t/+ahMTjw0wK/GmXjRrMNh1mfhXIMwj3hepeZ/sjoRNbap9GqsD7tViIlCf4ldsZSelqoHoQQgF4tiq1l+m3oxaKASvVSLWtE+KCAvO7bvAOnQt6uIMlUfIzy/tyI8yBGil0= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: iqvia.com X-MS-Exchange-CrossTenant-Network-Message-Id: d05a6e83-65a4-47cd-4680-08d763a1eb1a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 16:45:37.9797 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5989ece0-f90e-40bf-9c79-1a7beccdb861 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MqTNldtbEU5miZyCcA6t5ei0+P0PUv6Se0mXsVDDLTVNmJl5tZWvfuRlLi9qhhJLrV1ZTLjEhkb/UaFmFCUoWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4855 Archived-At: X-Mailman-Approved-At: Thu, 07 Nov 2019 11:11:18 -0800 Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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, 07 Nov 2019 16:45:46 -0000 --_004_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_ Content-Type: multipart/alternative; boundary="_000_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_" --_000_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGJvdGggZm9yIHJlcGx5aW5nLiAgVGhlcmUgYXJlIHR3byBpbnN0YW5jZXMgd2hl cmUgSSBoYXZlIGlkZW50aWZpZWQgQVJDIHNpZ25hdHVyZXMgY29uc2lzdGVudGx5IGZhaWxpbmc6 DQoNCkNhc2UgMTogIEFuIGludGVybWVkaWFyeSBTTVRQIHN5c3RlbSByZWNlaXZlcyBhbiBlbWFp bCBvbiBiZWhhbGYgb2YgYSByZWNpcGllbnQgc3lzdGVtIHdoZXJlYnkgdGhlIOKAnGZyb23igJ0g ZmllbGQgaXMgcmVxdWlyZWQgdG8gYmUgY2hhbmdlZCBmb3IgdGhlIGVtYWlsIHRvIHJlcGx5IGFz IGRlc2lyZWQgYnkgdGhlIHJlY2lwaWVudCBzeXN0ZW0uICAoZXhhbXBsZTogV2lsbGlhbS5XZWlz dEBnbWFpbC5jb20gcmV3cml0dGVuIHRvIFdpbGxpYW0uV2Vpc3RAaXF2aWEuY29tKQ0KDQpDYXNl IDI6IEFuIEludGVybWVkaWFyeSBTTVRQIHN5c3RlbSByZWNlaXZlcyBhbiBlbWFpbCBvbiBiZWhh bGYgb2YgdGhlIHJlY2lwaWVudCBzeXN0ZW0gd2hlcmVieSB0aGUg4oCcc3ViamVjdOKAnSBmaWVs ZCBpcyByZXF1aXJlZCB0byBieSBjaGFuZ2VkIGZvciB0aGUgZW1haWwgdG8gYmUgY2F0ZWdvcml6 ZWQgYXMgZGVzaXJlZCBieSB0aGUgcmVjaXBpZW50IHN5c3RlbS4gKGV4YW1wbGU6IOKAnFJFOiBb ZG1hcmMtaWV0Zl0gUXVlc3Rpb24gcmVnYXJkaW5nIFJGQyA4NjE34oCdIG1vZGlmaWVkIHRvOiAg 4oCcUkZDIENvcnJlc3BvbmRlbmNlOiBbZG1hcmMtaWV0Zl0gUXVlc3Rpb24gcmVnYXJkaW5nIFJG QyA4NjE34oCdKQ0KDQpBcyBLdXJ0IHBvaW50ZWQgb3V0IGJlbG93LCB0aGUgQVJDIHNpZ25hdHVy ZSBpcyBOT1QgaW50ZW5kZWQgdG8gYmUgdmFsaWRhdGVkIGJ5IGhvcHMgPjEgc3RlcCBhd2F5LiAg SG93ZXZlciwgSSBkaWQgbm90IHRoaW5rIHRoaXMgd2FzIHRoZSBjYXNlIGFuZCB0aGF0IEFSQyB3 YXMgc3BlY2lmaWNhbGx5IHN1cHBvc2VkIHRvIHZhbGlkYXRlIGVhY2ggY3VzdG9kaWFuIHdoZXJl IERLSU0gd291bGQgYmUgYnJva2VuIGJ5IHRoZSBjYXNlcyBsaXN0ZWQgYWJvdmUuDQoNCkFzIGRp ZmZlcmVudGlhdGVkIGZyb20gREtJTSwgdGhlIFJGQyByZWFkcyBhcyBpZiBBUkMgaXMgZGVzaWdu ZWQgdG8gdmFsaWRhdGUgdGhlIOKAnGN1c3RvZGlhbuKAnSBhbmQgTk9UIHRoZSDigJxzZW5kZXLi gJ0gdGhlcmVmb3JlLCDigJxGcm9t4oCdIGFuZCDigJxTdWJqZWN04oCdIHdvdWxkIG5vdCBiZSBh cyBkZXNpcmFibGUgYXMgc2F5IOKAnFgtUmVjZWl2ZWTigJ0sIOKAnFgtR29vZ2xlLVNtdHAtU291 cmNl4oCdLCBhbmQg4oCcWC1HbS1NZXNzYWdlLVN0YXRl4oCdIGluIHRoZSBjYXNlIG9mIEJyYW5k b27igJlzIGVtYWlsIHRvIHdoaWNoIEkgYW0gcmVwbHlpbmcuDQoNCkl0IGlzIG15IHN1Z2dlc3Rp b24gdGhhdCBmb3IgQVJDIHRvIGJlIGEgdmFsdWFibGUgYWRkaXRpb24gdG8gREtJTSwgaXQgbmVl ZHMgdG8gZm9jdXMgb24gdGhlIOKAnGN1c3RvZGlhbuKAnSBhbmQgbm90IHRoZSDigJxzZW5kZXLi gJ0uDQoNClRoYW5rIHlvdSBib3RoIGZvciB5b3VyIHRpbWUgYW5kIGF0dGVudGlvbi4NCi1CaWxs DQoNCkZyb206IEJyYW5kb24gTG9uZyA8YmxvbmdAZ29vZ2xlLmNvbT4NClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgNiwgMjAxOSAxMjo0MyBQTQ0KVG86IEt1cnQgQW5kZXJzZW4gKGIpIDxrYm90 aEBkcmt1cnQuY29tPg0KQ2M6IFdlaXN0LCBCaWxsIDxXaWxsaWFtLldlaXN0QGlxdmlhLmNvbT47 IGRtYXJjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIFF1ZXN0aW9uIHJlZ2Fy ZGluZyBSRkMgODYxNw0KDQpUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRo ZSBvcmdhbml6YXRpb24uDQoNCldoYXQncyBtb3JlLCB0aGUgcG9pbnQgb2YgaW5jbHVkaW5nIFN1 YmplY3QgYW5kIG90aGVyIG11dGFibGUgaGVhZGVycyBpcyB0aGUgc2FtZSBhcyBpdCBpcyBmb3Ig REtJTSwgdGhvc2UgYXJlIHRoZSBoZWFkZXJzIHdoaWNoIGFyZSBpbXBvcnRhbnQgdG8gdGhlIHJl Y2VpdmVyLCBzbyB0aGV5IHNob3VsZCBiZSB2YWxpZGF0ZWQuDQoNCkFzIEt1cnQgcG9pbnRzIG91 dCwgdGhlIHBvaW50IG9mIEFSQyBpcyB0byBhY2tub3dsZWRnZSB0aGVzZSBjaGFuZ2VzIGhvcCB0 byBob3AsIGFuZCB0aGUgQXJjIFNlYWwgcHJvdmVzIHdobyBkaWQgdGhlIGNoYW5nZSwgdGhlIHF1 ZXN0aW9uIGJlY29tZXMgZG8geW91IGJlbGlldmUNCnRoZSBwZXJzb24gd2hvIGNoYW5nZWQgaXQg d2Fzbid0IG1hbGljaW91cy4NCg0KQnJhbmRvbg0KDQpPbiBXZWQsIE5vdiA2LCAyMDE5IGF0IDc6 MzcgQU0gS3VydCBBbmRlcnNlbiAoYikgPGtib3RoQGRya3VydC5jb208bWFpbHRvOmtib3RoQGRy a3VydC5jb20+PiB3cm90ZToNClRoZSBjaG9pY2Ugb2Ygd2hpY2ggaGVhZGVycyBhcmUgaW5jbHVk ZWQgaW4gdGhlIHNpZ25lZCBzZXQgaXMgc3RyaWN0bHkgdXAgdG8gdGhlIGRvbWFpbiBhZG1pbmlz dHJhdG9ycyB3aG8gaW1wbGVtZW50IHRoZSBzaWduaW5nIHByYWN0aWNlcy4gQWxzbywgdGhlIEFN UyBpcyBvbmx5IHJlbGV2YW50IGZvciB0aGUgbmV4dCByZWNlaXZlciwgaXQgaXMgbm90IGludGVu ZGVkIHRvIGJlIHZhbGlkYXRlZCBieSBob3BzID4xIHN0ZXAgYXdheSBmcm9tIHRoZSBkb21haW4g d2hpY2ggYWRkcyB0aGF0IGluc3RhbmNlIHNvIEkgZG9uJ3Qgc2VlIGhvdyBtdXRhYmlsaXR5IHdv dWxkIG1hdHRlci4NCg0KLS1LdXJ0IEFuZGVyc2VuDQoNCk9uIFdlZCwgTm92IDYsIDIwMTkgYXQg NzozMCBBTSBXZWlzdCwgQmlsbCA8V2lsbGlhbS5XZWlzdEBpcXZpYS5jb208bWFpbHRvOldpbGxp YW0uV2Vpc3RAaXF2aWEuY29tPj4gd3JvdGU6DQpET0k6ICAxMC4xNzQ4Ny9SRkM4NjE3DQoNClRo ZSBpbmNsdXNpb24gb2YgdGhlIGFkZHJlc3MgaGVhZGVycyBpbiB0aGUgc2lnbmF0dXJlLCBhbmQg cG9zc2libHkgdGhlIFN1YmplY3QsIGlzIGFuIGlzc3VlOg0KDQpBUkMtTWVzc2FnZS1TaWduYXR1 cmU6IGk9MTsgYT1yc2Etc2hhMjU2OyBjPXJlbGF4ZWQvcmVsYXhlZDsgZD1taWNyb3NvZnQuY29t PGh0dHBzOi8vbmFtMDQuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGbWljcm9zb2Z0LmNvbSZkYXRhPTAyJTdDMDElN0NXaWxsaWFtLldlaXN0JTQwaXF2 aWEuY29tJTdDM2M2Njg1YWU1NTE0NDI4NzgwMTgwOGQ3NjJlMGRhYTUlN0M1OTg5ZWNlMGY5MGU0 MGJmOWM3OTFhN2JlY2NkYjg2MSU3QzElN0MwJTdDNjM3MDg2NTkwMTkxNDYwOTA4JnNkYXRhPUt5 WjdhQzRYMzVJY29qVE9FYmdlREZYbk9QUFNIdmx0OFJhcUg4VnRYcEElM0QmcmVzZXJ2ZWQ9MD47 IHM9YXJjc2VsZWN0b3I5OTAxOyBoPUZyb206RGF0ZTpTdWJqZWN0Ok1lc3NhZ2UtSUQ6Q29udGVu dC1UeXBlOk1JTUUtVmVyc2lvbjpYLU1TLUV4Y2hhbmdlLVNlbmRlckFEQ2hlY2s7IGJoPTsNCg0K SWYgYSBkb3duc3RyZWFtIHNlcnZlciBuZWVkcyB0byBtb2RpZnkgZWl0aGVyIG9mIHRoZXNlIHR3 byB2YWx1ZXMsIHRoZSBzaWduYXR1cmUgY2hlY2sgZmFpbHMuDQoNCkl0IGlzIG15IHVuZGVyc3Rh bmRpbmcgdGhhdCB0aGUgQXV0aGVudGljYXRlZCBSZWNlaXZlZCBDaGVjayBzaWduYXR1cmUgaXMg dG8gdmFsaWRhdGUgdGhlIGNoYWluIG9mIHBvc3Nlc3Npb24uICBBcyBzdWNoLCBpbiBteSBvcGlu aW9uLCB0aGUgc2lnbmF0dXJlIHNob3VsZCBvbmx5IGluY2x1ZGUgaW1tdXRhYmxlIHJlZmVyZW5j ZXMuDQoNCkluIG15IG9waW5pb24sIHRoZXJlIGlzIHZhbHVlIGluIE5PVCByZXF1aXJpbmcgaGVh ZGVycyB0byBiZSBzdHJpcHBlZCBieSBkb3duc3RyZWFtIHNlcnZlcnMsIHRodXMgbWFpbnRhaW5p bmcgdGhlIGN1c3RvZHkgY2hhaW4gZnJvbSBvcmlnaW5hdGlvbiB0byBkZXN0aW5hdGlvbi4NCg0K VGhhbmsgeW91IGZvciB5b3VyIHRpbWUgYW5kIGF0dGVudGlvbiwNCg0KV2lsbGlhbSBNLiBXZWlz dA0KRW50ZXJwcmlzZSBBcmNoaXRlY3QgSSDigJMgR2xvYmFsIE1lc3NhZ2luZyDigJMgTW9iaWxl IGFuZCBQcmVzZW5jZQ0KQ0lPIFRlYW0g4oCTIEVuZCBVc2VyIENvbXB1dGluZw0KW0lRVklBIGxv Z29fOTZkcGlfMTAwcHhoZWlnaHRdDQpMZWFybiBtb3JlPGh0dHBzOi8vbmFtMDQuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LmlxdmlhLmNvbSUy RiZkYXRhPTAyJTdDMDElN0NXaWxsaWFtLldlaXN0JTQwaXF2aWEuY29tJTdDM2M2Njg1YWU1NTE0 NDI4NzgwMTgwOGQ3NjJlMGRhYTUlN0M1OTg5ZWNlMGY5MGU0MGJmOWM3OTFhN2JlY2NkYjg2MSU3 QzElN0MwJTdDNjM3MDg2NTkwMTkxNDcwODk4JnNkYXRhPXclMkZJMGpTUlBYZTJGUmRwJTJGZ0oy NEVpS1FPM09YQmxCOVpPSmpsNEZWc3dFJTNEJnJlc2VydmVkPTA+IGFib3V0IElRVklB4oSiDQoN CjQwMCBDYW1wdXMgRHJpdmUNCkNvbGxlZ2V2aWxsZSwgUEEgMTk0MjYNClVTQQ0KDQpPOiArMSA2 MTAgMjQ0IDI2NDY8dGVsOig2MTApJTIwMjQ0LTI2NDY+IHwgTTogKzEgNDg0IDkwNCA4MjQ0PHRl bDooNDg0KSUyMDkwNC04MjQ0Pg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSU1QT1JUQU5UIC0gUExFQVNFIFJFQUQ6IFRoaXMgZWxlY3Ryb25pYyBtZXNz YWdlLCBpbmNsdWRpbmcgaXRzIGF0dGFjaG1lbnRzLCBpcyBDT05GSURFTlRJQUwgYW5kIG1heSBj b250YWluIFBST1BSSUVUQVJZIG9yIExFR0FMTFkgUFJJVklMRUdFRCBvciBQUk9URUNURUQgaW5m b3JtYXRpb24gYW5kIGlzIGludGVuZGVkIGZvciB0aGUgYXV0aG9yaXplZCByZWNpcGllbnQgb2Yg dGhlIHNlbmRlci4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBvciBk aXN0cmlidXRpb24gb2YgdGhpcyBtZXNzYWdlIG9yIGFueSBvZiB0aGUgaW5mb3JtYXRpb24gaW5j bHVkZWQgaW4gaXQgaXMgdW5hdXRob3JpemVkIGFuZCBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVs eSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cywgYWxvbmcgd2l0aCBhbnkgY29waWVz IHRoZXJlb2YsIGZyb20gYWxsIGxvY2F0aW9ucyByZWNlaXZlZCAoZS5nLiwgY29tcHV0ZXIsIG1v YmlsZSBkZXZpY2UsIGV0Yy4pLiBUbyB0aGUgZXh0ZW50IHBlcm1pdHRlZCBieSBsYXcsIHdlIG1h eSBtb25pdG9yIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMgZm9yIHRoZSBwdXJwb3NlcyBvZiBl bnN1cmluZyBjb21wbGlhbmNlIHdpdGggb3VyIGxlZ2FsIGFuZCByZWd1bGF0b3J5IG9ibGlnYXRp b25zIGFuZCBpbnRlcm5hbCBwb2xpY2llcy4gV2UgbWF5IGFsc28gY29sbGVjdCBlbWFpbCB0cmFm ZmljIGhlYWRlcnMgZm9yIGFuYWx5emluZyBwYXR0ZXJucyBvZiBuZXR3b3JrIHRyYWZmaWMgYW5k IG1hbmFnaW5nIGNsaWVudCByZWxhdGlvbnNoaXBzLiBGb3IgZnVydGhlciBpbmZvcm1hdGlvbiBz ZWU6IGh0dHBzOi8vd3d3LmlxdmlhLmNvbS9hYm91dC11cy9wcml2YWN5L3ByaXZhY3ktcG9saWN5 PGh0dHBzOi8vbmFtMDQuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnd3dy5pcXZpYS5jb20lMkZhYm91dC11cyUyRnByaXZhY3klMkZwcml2YWN5LXBv bGljeSZkYXRhPTAyJTdDMDElN0NXaWxsaWFtLldlaXN0JTQwaXF2aWEuY29tJTdDM2M2Njg1YWU1 NTE0NDI4NzgwMTgwOGQ3NjJlMGRhYTUlN0M1OTg5ZWNlMGY5MGU0MGJmOWM3OTFhN2JlY2NkYjg2 MSU3QzElN0MwJTdDNjM3MDg2NTkwMTkxNDcwODk4JnNkYXRhPUhlTWslMkJqUlhMVkp1WXhXcFFn TDhnMERpSE1Pc3RjckVBanVwcFRYVEhuYyUzRCZyZXNlcnZlZD0wPi4uIFRoYW5rIHlvdS4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbWFyYyBtYWls aW5nIGxpc3QNCmRtYXJjQGlldGYub3JnPG1haWx0bzpkbWFyY0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmM8aHR0cHM6Ly9uYW0wNC5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGZG1hcmMmZGF0YT0wMiU3QzAxJTdDV2lsbGlhbS5XZWlz dCU0MGlxdmlhLmNvbSU3QzNjNjY4NWFlNTUxNDQyODc4MDE4MDhkNzYyZTBkYWE1JTdDNTk4OWVj ZTBmOTBlNDBiZjljNzkxYTdiZWNjZGI4NjElN0MxJTdDMCU3QzYzNzA4NjU5MDE5MTQ3MDg5OCZz ZGF0YT1qMVRVN1BXamd4UUd2bWpmUTRSS1pHUVN6dlE3SXJ3VHRjSE1uVzZaQVFFJTNEJnJlc2Vy dmVkPTA+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZG1hcmMgbWFpbGluZyBsaXN0DQpkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPGh0dHBzOi8vbmFt MDQuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmRtYXJjJmRhdGE9MDIlN0MwMSU3Q1dp bGxpYW0uV2Vpc3QlNDBpcXZpYS5jb20lN0MzYzY2ODVhZTU1MTQ0Mjg3ODAxODA4ZDc2MmUwZGFh NSU3QzU5ODllY2UwZjkwZTQwYmY5Yzc5MWE3YmVjY2RiODYxJTdDMSU3QzAlN0M2MzcwODY1OTAx OTE0ODA4OTImc2RhdGE9Q3ZXMWE1THVhVVFCTlZPTlAlMkJaaVgwekNSc0p3dnVDeGIyJTJGQ2N1 UWV2aFUlM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFuayB5b3UgYm90aCBmb3IgcmVwbHlpbmcuJm5ic3A7IFRoZXJlIGFyZSB0d28gaW5zdGFuY2Vz IHdoZXJlIEkgaGF2ZSBpZGVudGlmaWVkIEFSQyBzaWduYXR1cmVzIGNvbnNpc3RlbnRseSBmYWls aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYXNlIDE6Jm5ic3A7IEFuIGludGVybWVkaWFy eSBTTVRQIHN5c3RlbSByZWNlaXZlcyBhbiBlbWFpbCBvbiBiZWhhbGYgb2YgYSByZWNpcGllbnQg c3lzdGVtIHdoZXJlYnkgdGhlIOKAnGZyb23igJ0gZmllbGQgaXMgcmVxdWlyZWQgdG8gYmUgY2hh bmdlZCBmb3IgdGhlIGVtYWlsIHRvIHJlcGx5IGFzIGRlc2lyZWQgYnkgdGhlIHJlY2lwaWVudCBz eXN0ZW0uJm5ic3A7IChleGFtcGxlOiBXaWxsaWFtLldlaXN0QGdtYWlsLmNvbSByZXdyaXR0ZW4N CiB0byBXaWxsaWFtLldlaXN0QGlxdmlhLmNvbSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2Fz ZSAyOiBBbiBJbnRlcm1lZGlhcnkgU01UUCBzeXN0ZW0gcmVjZWl2ZXMgYW4gZW1haWwgb24gYmVo YWxmIG9mIHRoZSByZWNpcGllbnQgc3lzdGVtIHdoZXJlYnkgdGhlIOKAnHN1YmplY3TigJ0gZmll bGQgaXMgcmVxdWlyZWQgdG8gYnkgY2hhbmdlZCBmb3IgdGhlIGVtYWlsIHRvIGJlIGNhdGVnb3Jp emVkIGFzIGRlc2lyZWQgYnkgdGhlIHJlY2lwaWVudCBzeXN0ZW0uIChleGFtcGxlOiDigJxSRTog W2RtYXJjLWlldGZdDQogUXVlc3Rpb24gcmVnYXJkaW5nIFJGQyA4NjE34oCdIG1vZGlmaWVkIHRv OiZuYnNwOyDigJxSRkMgQ29ycmVzcG9uZGVuY2U6IFtkbWFyYy1pZXRmXSBRdWVzdGlvbiByZWdh cmRpbmcgUkZDIDg2MTfigJ0pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIEt1cnQgcG9pbnRl ZCBvdXQgYmVsb3csIHRoZSBBUkMgc2lnbmF0dXJlIGlzIE5PVCBpbnRlbmRlZCB0byBiZSB2YWxp ZGF0ZWQgYnkgaG9wcyAmZ3Q7MSBzdGVwIGF3YXkuJm5ic3A7IEhvd2V2ZXIsIEkgZGlkIG5vdCB0 aGluayB0aGlzIHdhcyB0aGUgY2FzZSBhbmQgdGhhdCBBUkMgd2FzIHNwZWNpZmljYWxseSBzdXBw b3NlZCB0byB2YWxpZGF0ZSBlYWNoIGN1c3RvZGlhbiB3aGVyZSBES0lNIHdvdWxkIGJlIGJyb2tl bg0KIGJ5IHRoZSBjYXNlcyBsaXN0ZWQgYWJvdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IGRpZmZlcmVudGlhdGVkIGZyb20gREtJTSwgdGhlIFJGQyByZWFkcyBhcyBpZiBBUkMgaXMgZGVz aWduZWQgdG8gdmFsaWRhdGUgdGhlIOKAnGN1c3RvZGlhbuKAnSBhbmQgTk9UIHRoZSDigJxzZW5k ZXLigJ0gdGhlcmVmb3JlLCDigJxGcm9t4oCdIGFuZCDigJxTdWJqZWN04oCdIHdvdWxkIG5vdCBi ZSBhcyBkZXNpcmFibGUgYXMgc2F5IOKAnFgtUmVjZWl2ZWTigJ0sIOKAnFgtR29vZ2xlLVNtdHAt U291cmNl4oCdLCBhbmQg4oCcWC1HbS1NZXNzYWdlLVN0YXRl4oCdDQogaW4gdGhlIGNhc2Ugb2Yg QnJhbmRvbuKAmXMgZW1haWwgdG8gd2hpY2ggSSBhbSByZXBseWluZy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgaXMgbXkgc3VnZ2VzdGlvbiB0aGF0IGZvciBBUkMgdG8gYmUgYSB2YWx1YWJs ZSBhZGRpdGlvbiB0byBES0lNLCBpdCBuZWVkcyB0byBmb2N1cyBvbiB0aGUg4oCcY3VzdG9kaWFu 4oCdIGFuZCBub3QgdGhlIOKAnHNlbmRlcuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmsgeW91IGJvdGggZm9yIHlvdXIgdGltZSBhbmQgYXR0ZW50aW9uLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LUJpbGw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBCcmFuZG9uIExvbmcgJmx0 O2Jsb25nQGdvb2dsZS5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVt YmVyIDYsIDIwMTkgMTI6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IEt1cnQgQW5kZXJzZW4gKGIpICZs dDtrYm90aEBkcmt1cnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gV2Vpc3QsIEJpbGwgJmx0O1dp bGxpYW0uV2Vpc3RAaXF2aWEuY29tJmd0OzsgZG1hcmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtkbWFyYy1pZXRmXSBRdWVzdGlvbiByZWdhcmRpbmcgUkZDIDg2MTc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjOUM2NTAwIDEuMHB0O3BhZGRp bmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6I0ZCRUIxRiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPlRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXph dGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQncyBtb3JlLCB0aGUgcG9pbnQgb2Yg aW5jbHVkaW5nIFN1YmplY3QgYW5kIG90aGVyIG11dGFibGUgaGVhZGVycyBpcyB0aGUgc2FtZSBh cyBpdCBpcyBmb3IgREtJTSwgdGhvc2UgYXJlIHRoZSBoZWFkZXJzIHdoaWNoIGFyZSBpbXBvcnRh bnQgdG8gdGhlIHJlY2VpdmVyLCBzbyB0aGV5IHNob3VsZCBiZSB2YWxpZGF0ZWQuJm5ic3A7Jm5i c3A7PGJyPg0KPGJyPg0KQXMgS3VydCBwb2ludHMgb3V0LCB0aGUgcG9pbnQgb2YgQVJDIGlzIHRv IGFja25vd2xlZGdlIHRoZXNlIGNoYW5nZXMgaG9wIHRvIGhvcCwgYW5kIHRoZSBBcmMgU2VhbCBw cm92ZXMgd2hvIGRpZCB0aGUgY2hhbmdlLCB0aGUgcXVlc3Rpb24mbmJzcDtiZWNvbWVzIGRvIHlv dSBiZWxpZXZlDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 aGUgcGVyc29uIHdobyBjaGFuZ2VkIGl0IHdhc24ndCBtYWxpY2lvdXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyYW5kb248bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3Yg NiwgMjAxOSBhdCA3OjM3IEFNIEt1cnQgQW5kZXJzZW4gKGIpICZsdDs8YSBocmVmPSJtYWlsdG86 a2JvdGhAZHJrdXJ0LmNvbSI+a2JvdGhAZHJrdXJ0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBjaG9pY2Ugb2Ygd2hpY2ggaGVhZGVycyBhcmUgaW5jbHVkZWQgaW4gdGhlIHNpZ25lZCBz ZXQgaXMgc3RyaWN0bHkgdXAgdG8gdGhlIGRvbWFpbiBhZG1pbmlzdHJhdG9ycyB3aG8gaW1wbGVt ZW50IHRoZSBzaWduaW5nIHByYWN0aWNlcy4gQWxzbywgdGhlIEFNUyBpcyBvbmx5IHJlbGV2YW50 IGZvciB0aGUgbmV4dCByZWNlaXZlciwgaXQgaXMgbm90IGludGVuZGVkIHRvIGJlIHZhbGlkYXRl ZCBieSBob3BzDQogJmd0OzEgc3RlcCBhd2F5IGZyb20gdGhlIGRvbWFpbiB3aGljaCBhZGRzIHRo YXQgaW5zdGFuY2Ugc28gSSBkb24ndCBzZWUgaG93IG11dGFiaWxpdHkgd291bGQgbWF0dGVyLg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLUt1cnQgQW5k ZXJzZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gV2VkLCBOb3YgNiwgMjAxOSBhdCA3OjMwIEFNIFdlaXN0LCBCaWxsICZsdDs8YSBocmVm PSJtYWlsdG86V2lsbGlhbS5XZWlzdEBpcXZpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5XaWxsaWFt LldlaXN0QGlxdmlhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ET0k6Jm5ic3A7IDEwLjE3NDg3 L1JGQzg2MTc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBpbmNsdXNpb24gb2YgdGhl IGFkZHJlc3MgaGVhZGVycyBpbiB0aGUgc2lnbmF0dXJlLCBhbmQgcG9zc2libHkgdGhlIFN1Ympl Y3QsIGlzIGFuIGlzc3VlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QVJDLU1lc3NhZ2Ut U2lnbmF0dXJlOiBpPTE7IGE9cnNhLXNoYTI1NjsgYz1yZWxheGVkL3JlbGF4ZWQ7IGQ9PGEgaHJl Zj0iaHR0cHM6Ly9uYW0wNC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHAlM0ElMkYlMkZtaWNyb3NvZnQuY29tJmFtcDtkYXRhPTAyJTdDMDElN0NXaWxsaWFtLldlaXN0 JTQwaXF2aWEuY29tJTdDM2M2Njg1YWU1NTE0NDI4NzgwMTgwOGQ3NjJlMGRhYTUlN0M1OTg5ZWNl MGY5MGU0MGJmOWM3OTFhN2JlY2NkYjg2MSU3QzElN0MwJTdDNjM3MDg2NTkwMTkxNDYwOTA4JmFt cDtzZGF0YT1LeVo3YUM0WDM1SWNvalRPRWJnZURGWG5PUFBTSHZsdDhSYXFIOFZ0WHBBJTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+bWljcm9zb2Z0LmNvbTwvYT47DQogcz1hcmNz ZWxlY3Rvcjk5MDE7IGg9PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5Gcm9tPC9zcGFu PjpEYXRlOjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+U3ViamVjdDwvc3Bhbj46TWVz c2FnZS1JRDpDb250ZW50LVR5cGU6TUlNRS1WZXJzaW9uOlgtTVMtRXhjaGFuZ2UtU2VuZGVyQURD aGVjazsgYmg9OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgYSBkb3duc3RyZWFtIHNl cnZlciBuZWVkcyB0byBtb2RpZnkgZWl0aGVyIG9mIHRoZXNlIHR3byB2YWx1ZXMsIHRoZSBzaWdu YXR1cmUgY2hlY2sgZmFpbHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBteSB1 bmRlcnN0YW5kaW5nIHRoYXQgdGhlIEF1dGhlbnRpY2F0ZWQgUmVjZWl2ZWQgQ2hlY2sgc2lnbmF0 dXJlIGlzIHRvIHZhbGlkYXRlIHRoZSBjaGFpbiBvZiBwb3NzZXNzaW9uLiZuYnNwOyBBcyBzdWNo LCBpbiBteSBvcGluaW9uLCB0aGUgc2lnbmF0dXJlIHNob3VsZCBvbmx5IGluY2x1ZGUgaW1tdXRh YmxlDQogcmVmZXJlbmNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG15IG9waW5p b24sIHRoZXJlIGlzIHZhbHVlIGluIE5PVCByZXF1aXJpbmcgaGVhZGVycyB0byBiZSBzdHJpcHBl ZCBieSBkb3duc3RyZWFtIHNlcnZlcnMsIHRodXMgbWFpbnRhaW5pbmcgdGhlIGN1c3RvZHkgY2hh aW4gZnJvbSBvcmlnaW5hdGlvbiB0byBkZXN0aW5hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoYW5rIHlvdSBmb3IgeW91ciB0aW1lIGFuZCBhdHRlbnRpb24sPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+V2lsbGlh bSBNLiBXZWlzdDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5FbnRlcnByaXNlIEFyY2hpdGVj dCBJIOKAkyBHbG9iYWwgTWVzc2FnaW5nIOKAkyBNb2JpbGUgYW5kIFByZXNlbmNlPC9zcGFuPjwv aT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPkNJTyBUZWFtIOKAkyBFbmQgVXNlciBDb21wdXRpbmc8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjEzIiBoZWlnaHQ9IjEwMCIgc3R5 bGU9IndpZHRoOjIuMjE2NmluO2hlaWdodDoxLjA0MTZpbiIgaWQ9ImdtYWlsLW1fLTMyNzA4MTc2 OTY0MzkxNTQyMTFnbWFpbC1tXy05MDU5MjAxNzM3MzM4MDkyMzE1UGljdHVyZV94MDAyMF8xIiBz cmM9ImNpZDppbWFnZTAwMS5qcGdAMDFENTk1NUUuQTVBODQzMzAiIGFsdD0iSVFWSUEgbG9nb185 NmRwaV8xMDBweGhlaWdodCI+PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+PGEgaHJlZj0iaHR0cHM6 Ly9uYW0wNC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYl MkZ3d3cuaXF2aWEuY29tJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NXaWxsaWFtLldlaXN0JTQwaXF2 aWEuY29tJTdDM2M2Njg1YWU1NTE0NDI4NzgwMTgwOGQ3NjJlMGRhYTUlN0M1OTg5ZWNlMGY5MGU0 MGJmOWM3OTFhN2JlY2NkYjg2MSU3QzElN0MwJTdDNjM3MDg2NTkwMTkxNDcwODk4JmFtcDtzZGF0 YT13JTJGSTBqU1JQWGUyRlJkcCUyRmdKMjRFaUtRTzNPWEJsQjlaT0pqbDRGVnN3RSUzRCZhbXA7 cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPkxlYXJuDQogbW9yZTwvYT4gYWJvdXQgSVFWSUHi hKI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+NDAwIENhbXB1 cyBEcml2ZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5Db2xsZWdldmlsbGUsIFBBIDE5NDI2PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0Ij5VU0ENCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0Ij5POg0KPGEgaHJlZj0idGVsOig2MTApJTIwMjQ0LTI2NDYiIHRhcmdldD0iX2JsYW5r Ij4mIzQzOzEgNjEwIDI0NCAyNjQ2PC9hPiB8IE06IDxhIGhyZWY9InRlbDooNDg0KSUyMDkwNC04 MjQ0IiB0YXJnZXQ9Il9ibGFuayI+DQomIzQzOzEgNDg0IDkwNCA4MjQ0PC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2NvbG9yOiM5MjhFOEUiPklNUE9SVEFOVDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtjb2xvcjojOTI4RThFIj4gLSBQTEVBU0UgUkVBRDogVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UsIGluY2x1ZGluZyBpdHMgYXR0YWNobWVudHMsIGlzIENPTkZJREVOVElBTCBh bmQgbWF5IGNvbnRhaW4gUFJPUFJJRVRBUlkgb3IgTEVHQUxMWSBQUklWSUxFR0VEIG9yIFBST1RF Q1RFRA0KIGluZm9ybWF0aW9uIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGF1dGhvcml6ZWQgcmVj aXBpZW50IG9mIHRoZSBzZW5kZXIuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZGlzY2xvc3VyZSwgY29w eWluZywgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVzc2FnZSBvciBhbnkgb2YgdGhlIGluZm9y bWF0aW9uIGluY2x1ZGVkIGluIGl0IGlzIHVuYXV0aG9yaXplZA0KIGFuZCBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFz ZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIHBlcm1h bmVudGx5IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cywgYWxvbmcgd2l0 aCBhbnkgY29waWVzIHRoZXJlb2YsIGZyb20gYWxsIGxvY2F0aW9ucyByZWNlaXZlZCAoZS5nLiwg Y29tcHV0ZXIsIG1vYmlsZQ0KIGRldmljZSwgZXRjLikuIFRvIHRoZSBleHRlbnQgcGVybWl0dGVk IGJ5IGxhdywgd2UgbWF5IG1vbml0b3IgZWxlY3Ryb25pYyBjb21tdW5pY2F0aW9ucyBmb3IgdGhl IHB1cnBvc2VzIG9mIGVuc3VyaW5nIGNvbXBsaWFuY2Ugd2l0aCBvdXIgbGVnYWwgYW5kIHJlZ3Vs YXRvcnkgb2JsaWdhdGlvbnMgYW5kIGludGVybmFsIHBvbGljaWVzLiBXZSBtYXkgYWxzbyBjb2xs ZWN0IGVtYWlsIHRyYWZmaWMgaGVhZGVycyBmb3IgYW5hbHl6aW5nIHBhdHRlcm5zDQogb2YgbmV0 d29yayB0cmFmZmljIGFuZCBtYW5hZ2luZyBjbGllbnQgcmVsYXRpb25zaGlwcy4gRm9yIGZ1cnRo ZXIgaW5mb3JtYXRpb24gc2VlOg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNC5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlxdmlhLmNvbSUyRmFi b3V0LXVzJTJGcHJpdmFjeSUyRnByaXZhY3ktcG9saWN5JmFtcDtkYXRhPTAyJTdDMDElN0NXaWxs aWFtLldlaXN0JTQwaXF2aWEuY29tJTdDM2M2Njg1YWU1NTE0NDI4NzgwMTgwOGQ3NjJlMGRhYTUl N0M1OTg5ZWNlMGY5MGU0MGJmOWM3OTFhN2JlY2NkYjg2MSU3QzElN0MwJTdDNjM3MDg2NTkwMTkx NDcwODk4JmFtcDtzZGF0YT1IZU1rJTJCalJYTFZKdVl4V3BRZ0w4ZzBEaUhNT3N0Y3JFQWp1cHBU WFRIbmMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmlx dmlhLmNvbS9hYm91dC11cy9wcml2YWN5L3ByaXZhY3ktcG9saWN5PC9hPi4uIFRoYW5rIHlvdS4g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtYXJjIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmRtYXJjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDQuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmRtYXJjJmFtcDtkYXRhPTAyJTdDMDElN0NXaWxs aWFtLldlaXN0JTQwaXF2aWEuY29tJTdDM2M2Njg1YWU1NTE0NDI4NzgwMTgwOGQ3NjJlMGRhYTUl N0M1OTg5ZWNlMGY5MGU0MGJmOWM3OTFhN2JlY2NkYjg2MSU3QzElN0MwJTdDNjM3MDg2NTkwMTkx NDcwODk4JmFtcDtzZGF0YT1qMVRVN1BXamd4UUd2bWpmUTRSS1pHUVN6dlE3SXJ3VHRjSE1uVzZa QVFFJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbWFyYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbWFyY0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA0LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZkbWFyYyZhbXA7ZGF0YT0wMiU3QzAxJTdDV2lsbGlhbS5XZWlzdCU0MGlxdmlhLmNv bSU3QzNjNjY4NWFlNTUxNDQyODc4MDE4MDhkNzYyZTBkYWE1JTdDNTk4OWVjZTBmOTBlNDBiZjlj NzkxYTdiZWNjZGI4NjElN0MxJTdDMCU3QzYzNzA4NjU5MDE5MTQ4MDg5MiZhbXA7c2RhdGE9Q3ZX MWE1THVhVVFCTlZPTlAlMkJaaVgwekNSc0p3dnVDeGIyJTJGQ2N1UWV2aFUlM0QmYW1wO3Jlc2Vy dmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RtYXJjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_-- --_004_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6018; creation-date="Thu, 07 Nov 2019 16:45:37 GMT"; modification-date="Thu, 07 Nov 2019 16:45:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABkANUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKo65qB0jRr++CeabW3knCE43bVLYz74ry/wn8dp9e+I2k+HLzQhYafqnh+11W31QXQdTdSo0j2 hXAwVjQuGz8wDcDHOkacppuPQzlUjFpPqevUV8/2v7Tl3qOj398NAttJtj4lTQ7DUNUvtlobZ4PO jvbhwv7pJB8qLzlnjBI3cekeIPHV/wCEfhXqHinVrSxN3Y2j3UsNreF7Zgp+8spUfKV+bJHFaSoV INKS3IjWhO9nsdxRXnd18a/D8fjKy0e31TS7uxfSrzVLvUIb9HW1WB4V+YLnAPmnkkY2981tR/E7 w1NpMupJqe+2inFtIqwSmZJSu4IYtu8Er8wG3kc9KzdOas2i1Ug20nsdVRXl/if456T4XuJr+aSO 88NrpEGpR3lkGleRpbjyVCgcFeh/OrVn8adDXxvqWhahqNnZBfsJsGferzC5QlN+RhNzqVXOMkY6 1XsZ2vb+v6Ye0he1z0aivK/jN8ZLj4X32i2lvp1teT6lFcPbpdXPlNeTRBCtlbqAS9xKGYouMYjb JrqvG/j+08EeDbzX5oJL0wmOCOytmUyzXMkixRwAk7QzSOqckAE80vZTtF2+LYPaRV79NzqqK81h +IHijw3rWg2vjHRNOs7PWpDaxXmkXklwtpciN5BFNvjXKlY3AkHG4AEDIrY1j4naJa+Gzqdhqum3 Hm6b/ats1zcmKGW2yo84uFbCfOvzYP3hQ6U7pW3Eqke52VFci3xX8JL4hl0I69af2vFM1tJaBiWW ZYhMYjxjzPLO8J94ryARXJyfHux1jwTceIvDwtriFdJ1K/jh1B3hmaS1AIUR7fmQ5+ZgRtyvBzwK lN9AdSEd2etUVytn8R9Ck1Gy0q41GGLV51jBtgGwsjxh1jLY2hypyFJ3Ec4q94c8a6L4skuU0i/j vjbkeYY1YDBJAZSQAykqRuXI4PPFS4yWrRfNF9TcorkZfix4St4dUmn1y2tYNLiae7luN0SRRK21 pNzAAoG4LDIB6mlHxV8KG4sof7ahEl4I2i3I4GHYrGWJGE3sCF3Y3ds0ezn2Fzx7nW0Vy3iz4n+F vA90ltr2uWmmXDW7XYjmY7vJVgrykAHCKWXcx4XIyRTr74meF9N16HRbnW7WHUpWiRYSxIDSf6pW YDarP/CpILds0ck7XsHPHa509FczD8SvC89xY26a7Yme+gubm2i80B5Yrdglw4B5xGxAb0JxW7pu o22r6fa31nMtxaXUSzQzJ910YAqw9iCDScWt0VdPYs0UUVIwooooAKKKKAKOt6edX0e/sQ/lG6t5 IPMxnbuUrnHfGa8l1f8AZ2OreHJ9OHiO4sLo2OlWltqFnCFmtns1dHkXJP8ArY5HQjsGPNeyTTJb wvLIwSNFLMzdAAMk15pa/tKfDi9mMdv4nt5nAzhY5DwO/wB2uyhDESTlRi2lvZXt6nHXq4anKMa8 0m9ru1/QlX4Y6noLa8/h3UdNgi1O9gn+wajp5ntxbx2kdv8AZ8K6nH7oPu/DBqHSvgsul/BW68Aj U1b7VHcK9wtsFhiM0rSskUO4hIl3FUjydqgDJxVz/hf/AID/AOhgi/79Sf8AxNcv4i/bM+DnhLUf sGseOLPTrsoJBFPFKpZT/EPl5H0q1DFS91Qb26dvkJSw17qS69e+5ufET4G6f48vFkjuI9IiGl3N gVtrVQS8ksEiSEjGQrQfd7hjyKz2+C2rtbidNZsrLUpNSjvL1bO3nSG/hSFo1hnYzGVgpbzAQ4GV VSCuQdP4X/tJfDX4zaxd6V4N8WWWu6jawfapbaDcHWLdt34YDI3YH4itf4ufFC0+EfhI69e2U9/C J44BDbkBstnnJ44ANOEMVKpHDKL5nok139Sa1TDUaU8TUlaMdW+1vQ4+z/Z9nsfB76NDr6iddF/s uK6Nn8qyC5a4SUpv5XJAKZ6DrW7rPwnuvEFvr7XeqQpeaxJpk0zw2pCI9o6OdoLE4Yrxk/LnvXoV ndLe2cFwgISVFkAbrgjI/nXN/ED4neHfhjpYvtf1BbVX4ihQF5piOoRBycdz0HesoOvWqKEFeTey Wt/6RpUlQw9J1KslGKWrbsrHJ/E/4K3Pj7X7rULfV4bRL7To9Nm+02zSy2XlytIlzZuHXyZgXJ3c 5KRn+DBuad8F4F+D6eAtR1KSdIV/dataxLDc+akvmxXTZ3KbgSBZGbGGcE7QDivPP+Gyba63T6f4 E8Q32nA/8fSIMY9eAR+tehfC/wDaD8JfFaX7Lp11JZaqF3HT75dkpA67Tkq+O+Dkd69Otl+Y4elz VKbUY69Hb1tt8zxsPm+U4qt7OlVTlLbdX9L2v8jP1D4X+NvEHiXw5e634w0u/wBM0WZp1sYdGeE3 ErRtF5rsJyN6pI+0AbQzbsHAxk2v7PerN4dbRr7xRBNbW/h5/Ddk8Wn7HWHzY3SaQ7zuk2xqpA2q TyAM4r2LxBqw0HQ9Q1I2812LO3kuPs9uMySbFLbVHcnGBXn/AOzv8fdF/aK+H8fibSLWfTJFma3u 9Nu3RprWQYIDFSQQylWBHUNXnKdZwdSPwq3Redv1PZdOip8r3d+r8v8AgF64+FZmu5JxqKqX8Tx+ IseR/diWPys577Pve+MVg/8ACjb+40GTSrrX4Xjj0/WNMtZY7Iqyw3rKVLguQzx7cEjAb0FewU2R 1jVmZgqqMlmOAB61gq01szZ0oPdHkNr8Bfsni6e/+2WV5pN3qVvrFxa3trJJItzFDHGpjIlCAboY 3DMjMpBAOCNu/wDDX4caj4J1HV57jV4pLO7VEh0uwgaG0gZWctMkbu+x33gMqkJ8gIUEnOD8Cf2k tG+P2s+MrbQtKv4NP8PXi2iapOUa3vwd3zxlSSB8ucNztZW6NVj4gftCaZ8PfjL4D+Hl1pN9d3vi 0SmG+gZBDbbOm8E7juII+UHHeumUcQ5OjJa2202Sv+XzMIOgoqrF6N7+r/zMCP8AZx1G7+1HVfFP 9pTSaXcaWbqa2Z5bhZbiKbzZS0hG791t2oFT5jgdAOg8TfBP+3PGmpasl1ZyafrEtrLqFnf28s3z QBQvl7ZVXkKv31baRuHpXqtLWH1ipe9zVUaa0scR4o+HP/CSeINS1I3qwi88P3Gh+WYQ23zX3eZn POP7veuVm+BupY1LTLfxBDF4e1i7s77UYjYBrrzYI4UKxS7sKri3j+8rMnzbTyu2n+0F+1b4X/Z4 1fw1p2s2l3qNxq8u6VbNkH2G1DBXuZNxGVBYfKPmOGIHBr2i2uYry3ingkWWGVA6SIchlIyCD6EV f76lCM2rJ7fIm1KpJxvqt9e54l4h/ZpbWbzxFcQeJprGTUNSjurFktEJ061dg19aoc8rclpizHkG QY+4K9ttreO1gjhiQRxRqERFGAqgYA/KuA1/4rS+FdYNvqOjk2H25rI3ltciQx/6P5yyOhUEAkpH gZIZx2ya6zwfrz+KPC+lavJZyadJe20c72crh3gZlBKMRwSp4JHHFTUdWUU57fL+un9XKh7OMmo7 /wBf5/1Y2KKKK5jcKKKKACub+IGr+IND8M3F34Z0WPX9WR0CWMk4hDKWAY7j6DnFdJXnPxY+FzeP ms7tvF+teGIbCKQyDS5/LRwcEs/uAP1NdeFVN1o+1do+abXpZWeu2hw411lh5+wTcraWaT9U2mtN 9Uzm9O+IXxburdzefDi1tn3Y8v7crZGOuQfrWWsXitJDIvwg0FXJzuHlg1x+mX3gGaNLe3+M+s3D In3t7liBxknFXv8AijP+iva1/wB9P/hXs1qbp1JJU+W/Tlmvzdzw8PUVWlFurztdeam9fVK33HTe Z4x/6JJof/fUdct8QF8fLpUd1pfwD8L+I9QjkVBbXckKYjJ+YqxB6enen/8AFGf9Fe1r/vp/8K5b 4mXXw5t/CNymr/HzXvDdrM6RjUIZ2jkRt2QFYqeTjH0rOnH317v4T/RnS5X0Uvxh/keifs23nj6b xJq6eKvgtoPwzsfsiGK/0q6ikkuZN5/dFUXO0DnJPWrP7av/ACRg/wDYRg/k1cP+x/L8Pj401seE fjxrvxTvXsFMml6reebHBGJP9cqlRzkhcg9xXcftq/8AJGT/ANhGD+TV04KPLnFFWt70ejX/AKVd nJnF/wCw8Um9eSXZ9PJL8j2TTr2LTfCltdztthgskldvRVjBP6Cvm/4K+Dx8f/FurfEjxdD9r09b k2+madNzEFU5GV7qoI+XoW3E54x77q+ny6t8L7uyg5muNIaJB6sYcCvMP2Mtatr34QR6ch23mm3k 0VxERhlLNvUkfQ4/A1lhZSoYLEV6Xx3jG/VRd7/e0kTjoQxWZ4TDV9afLOVukpR5Ur97JtnusVvH bwrFEixxqMBEUBQPTArwz9or4K2mqaHdeL/DkA0zxVpQ+2CazGxrhU5OcfxgDKt14wcgmvd84rnP iLr1p4a8C69qV64S2t7KVmz3JUgKPckgfjXl4HEVsPiITo73Wnfyfe57OZ4XD4vCTp4j4Um7/wAt luuzRj/BP4gN8TvhppGuTBReSIYboKML5yHa5A9CRn8a+UbFv+GPP2ypLJj9l+HXxGO+LtFbXTPw OvG2V8f7s6dkr3j9jfS7jTfgrZyTqyi6u5541YY+TdtBHsdpNH7YnwOHxz+DOpafawh/EGm51HSm zgmZFO6PPYSIWT6kHtXp1fY4bMK2G/5dNuPpro/kzzcHKvjMqw2Kl/FUYy9XbX/wJHuNfM37dnxm ufh/8M4fCmgPI/i7xhJ/ZtnDbtiVYWIWV1wcgtuWNT/ekB7Gtr9j349xfFr4HwX2tXQi13w8hsdZ af5WBjXKzMMcbkAY+jBh2rxr9ne1uP2qv2nPEPxj1OJm8J+G3+weHYZR8rOAdjgeoRmkPH3plHVK 5cPhvYVpzrrSnv5vovn+R6NfEKtShCi9am3kur+X5n0n+zX8GbX4E/CPRvDMaxm/VPtOozxjAmun AMh+g4UeiqBXg/7S/wDyfJ+z1/22/wDQmr7Jr42/aX/5Pk/Z6/7bf+hNU4KpKriJzm7txn/6SzTF QjToRhFaJx/9KR9k1R13WrLw3ot9qupXKWmn2MD3NxPI2FjjRSzMT7AVer49/bw+IWp+Jbjw18D/ AAlJv8Q+LbiM3uw58q13fKr89GKs7A9Uicd64sNQeIqqnsur7LqzpxFb2FJz3fTzfRHl/wAN/hBd ftyeIPij8S/EXm2Wn3cUmk+FxIDiCRAfLcj+IRgjI6F5ZQegr2j9gX4sX2veB9S+G/iXfB4s8ETG xkhmbLtbBiqc99jK0ee4VT/FXq/w61P4cfB3wTpPgzT/ABTodtBo8ItWWTUIlkaQf6xn+b77NuJz 3NfMn7RV5a/BD48+Ffj94PurfVPDOpT/ANl+JP7NlWWNm2gMSVyMtGoPrvgjH8Ve37X6854a1o/Y 8rLRfNfieOqX1PkxF7y+3536/wDbr/A+6WtYZGLNEjHOcsoPOMZ/SnxxrGoVFCKOiqMAVX0vU7XW tNtb+ynW5s7qJZoZozlXRgCrA+hBq3XzfkfQhRRRSAKKKKACkZQ6lWAZSMEEZBpaKAPHfifp2reF 7zTx4O+F+jeJIpUc3EziKExMCMLg4zkEnPtWHb3njaS3jaT4RaLHIygsmY/lPcV77j2owPSvR+uX pxg4Jtdbyu/XW33JHlLAuNWVRVWk/s2jZenu3+9s8G+0eMv+iS6L/wCQ68/8feIvizHqaWmk/s4e H/ENhGgdri7uYI18w9lU5PA7nFfXO0elG0elTHFKLu6af/gX6M2eFb/5eP8A8l/yPnv9m/UPH934 k1dfFnwX0P4aWItEMWoaXcxPJcSbz+6KoM4A5zmr37ZttNdfBtkghknf+0IPljQsedwHT3IH417t j2pGUMMEZHvWlDG+xxcMUoL3WnZN9PN3ZjjMD9bwVTBufxpq9l18lYpaEjR6Lp6spVlt4wVIwQdo 4r568dfC7xf8J/H1147+G8X9oWV5l9S0HGdxJy21eNyk5bj5lJOMgkV9KUlThcbPCVJSik4y0aez X9bMWPy2lj6cYTbjKDvGS0cX3X6p6M+TfHn7U1n4u8D6r4bv/C/iLQ9avrYwDyF/1cnbk7WK56jG SM1yHw8h8bftERad4I1LVxY+H/DyxtfM24XUq5IXIbl3GCoJwF4JycV9utbxu4do1Zh0YqCa5zS/ ht4f0fxpqXiuz09Ydc1GMRXNwHbDKMfw5wCcDJHXAr3aOcYXD0ZwoUOSW8XfmtLbra2nrrbQ+XxH D2NxWIhUxWK9pD4ZK3JeG9nyt3963RaXV0bejaRaaBpVppthAttZWsSwwwp0VFGAKuGlor5Jtyd3 ufexiopRirJH5rftUfCnxh8J/jHreneAIbhdD+LMQsmtbaBmj+0NJ+9hJUfuwS5l3f3Wm7CvvD4K fC3T/gz8M9D8J6fh1sYf38+MG4nb5pZT7s5Jrt2QMQSASDkcdKdXoYjGzxFKFKS238+iv6LQ4aGD hQqyqJ77eXV29XqFfHv7SGn3dz+29+z5NDZ3M0Ki4LTRwO8abSSdzAYXAPcivsKmlAzBiASOhx0r nw9b2E3O19GvvTX6nRWpKtFRb6p/c7lPWtTXRdHvtQkilnS1gknaKFSzuFUttUDqTjgV8ffsS+Dt W+KXjjxZ8ffF1pNDqGszyWui29zGymC34DsobBACqkQ452Ow4evs6kVFjUBQAB2AxTp13SpThFay sr+XVfPQmpRVSpCcnpHW3n3+R80ah/wTr+CWpaleXsmgX8ct1cSXMixanMq75HLtgbuBuY8ds11N r+yB8PtB+Dfin4d6Dp0mn6XrzNcyzSzNNKt1tURzBnzgoUQjH92vcKSrljcTJJSqN2830EsLQTbU Fd76dz5U/YF8WeI7bwn4k+GniqwurfVPA179hS4khdYmhYsVjV2ABCkHbjP7toz3r6spoUKxIGCe vvTqyxFVV6sqiVr/ANP8S6FN0aapt3sFFFFc5uFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//Z --_004_BYAPR05MB4167E31DE0CC7377CEACF1A5FA780BYAPR05MB4167namp_-- From nobody Thu Nov 7 15:16:20 2019 Return-Path: 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 C914F12002F for ; Thu, 7 Nov 2019 15:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hfiSvkCG65O3 for ; Thu, 7 Nov 2019 15:16:16 -0800 (PST) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC20A1200B1 for ; Thu, 7 Nov 2019 15:16:16 -0800 (PST) Received: by mail-vs1-xe43.google.com with SMTP id a143so2507833vsd.9 for ; Thu, 07 Nov 2019 15:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FoakIaRoMdjfRK7u041DXGzP2KQkaSt4+QtydErJtEc=; b=eD7MPysLIXxpQrZSNwv/qhub4aNj3rMJfS+VJm2lvkb6CMPuMUXGHqxGM2kRNiqbHt q15gYRrx02nCzP0/BN9SnMYszxuULEZZJGBRg5ECh9/Vx6tBq8WQ740m0z0wesktWt+f M0HzaIaFf7n2qlDBPHrNZkHuduJMz473mXmySyqOYBpdkTLlEa+ueuAQxvCq9FE5R33G gF0RrNhiAyGLgMWwQ671kuMzuJ2w1nqTr/MjG4FiMSDjuJ35Pmx2ybJxgr3NN8c13rBf ZNek/2tV3M0v/PVMdZmlzcIRrZA5j67/01i082168AAoEjazPe5kufMCP9JTFdA2VpAX Rb7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FoakIaRoMdjfRK7u041DXGzP2KQkaSt4+QtydErJtEc=; b=r+8nz3oIXE2cSAyWdF+MdcJZ51s+p4MlrML3LhQ0IFKe3T+k3sjNkUBAwv3WvLl8MW cWyJSU+5WUqdqveC3JgE32JUFE/OzMnqRp05ed/X+e3OBoIFRdYMWrRrs7zsVdMPT9Xn 5BHPyI13RHEOdB5xmIvb37vwfUytjKTma1IMT67e5z6BLxc0bBSEX6fzR0ZgwG1RuZ4b vOwvQk91o2Th/Ub2z9leUqcaJB9obHIwuY436IsJyR66inTXjxPhKSKwYcy/4QL9Nt4h NcckHdeKo8mgRkP6ws3MZSFPOH2VLNkG39y28z2SA78AxwS3S2rIlslaj/KA9OUmnXp0 8Eww== X-Gm-Message-State: APjAAAVxTy4mft8xsy78JJ1knpvVQs1EjUC6BqzpuEd8RQpRWn/aJLMj c4ReREk6yy7kGWCzRcEiZa28vfHeS9gqAPUt0yIZ X-Google-Smtp-Source: APXvYqx11x6ReP4EOahgajMTJPkDf46R2JOSoYAPju5y+RLzO2c0siL4hBwQfCn+qu0maDXdD/IJq2XdctgYMQwDBzY= X-Received: by 2002:a67:f74f:: with SMTP id w15mr5078176vso.131.1573168574877; Thu, 07 Nov 2019 15:16:14 -0800 (PST) MIME-Version: 1.0 References: <2b25082c-34b2-93f6-9412-6b669652e317@gmail.com> In-Reply-To: <2b25082c-34b2-93f6-9412-6b669652e317@gmail.com> From: Brandon Long Date: Thu, 7 Nov 2019 15:16:02 -0800 Message-ID: To: Dave Crocker Cc: Brandon Long , "Kurt Andersen (b)" , "dmarc@ietf.org" , "Weist, Bill" Content-Type: multipart/alternative; boundary="0000000000001477a60596c9da39" Archived-At: Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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, 07 Nov 2019 23:16:19 -0000 --0000000000001477a60596c9da39 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 7, 2019 at 9:28 AM Dave Crocker wrote: > On 11/6/2019 9:43 AM, Brandon Long wrote: > > What's more, the point of including Subject and other mutable headers is > > the same as it is for DKIM, those are the headers which are important to > > the receiver, so they should be validated. > > > This being a technical list, I'm going to get picky and note that DKIM > does not 'validate' those fields. > > There is a derivative data integrity benefit, between signing and > validated, for such fields, but that is quite different from any claim > that the contents of those fields are 'valid'. > > Some signing sites have much more stringent uses of DKIM than are > provided by the standard. That's fine, of course, but it has nothing to > do with the standard. Hence any receive-side reliance on such signer > data validation is outside the DKIM standard. > I should have said "covered by the signature". And I think they are important to both the sender and receiver, your DKIM RFC calls them "core to the message content" and so the "core of the message is valid"... which is different than validated, of course. For ARC, this still holds true, that AMS is analogous DKIM, and should cover the core of the message, and ARC allows for you to know if and between which hops the core of the message was modified. Brandon --0000000000001477a60596c9da39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 7, 2019 at 9:28 AM Dave C= rocker <dcrocker@gmail.com>= wrote:
On 11/6/= 2019 9:43 AM, Brandon Long wrote:
> What's more, the point of including Subject and other mutable head= ers is
> the same as it is for DKIM, those are the headers which are important = to
> the receiver, so they should be validated.


This being a technical list, I'm going to get picky and note that DKIM =
does not 'validate' those fields.

There is a derivative data integrity benefit, between signing and
validated, for such fields, but that is quite different from any claim
that the contents of those fields are 'valid'.

Some signing sites have much more stringent uses of DKIM than are
provided by the standard.=C2=A0 That's fine, of course, but it has noth= ing to
do with the standard.=C2=A0 Hence any receive-side reliance on such signer =
data validation is outside the DKIM standard.

I should have said "covered by the signature".
<= br>And I think they are important to both the sender and receiver, your DKI= M
RFC calls them "core to the message content" and so t= he "core of the
message is valid"... which is different= than validated, of course.

For ARC, this still holds true, that AMS= is analogous DKIM, and should cover
=C2=A0the core of the messag= e, and ARC allows for you to know if and between which hops
the c= ore of the message was modified.

Brandon
--0000000000001477a60596c9da39-- From nobody Thu Nov 7 15:45:57 2019 Return-Path: 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 C1797120018 for ; Thu, 7 Nov 2019 15:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.299 X-Spam-Level: X-Spam-Status: No, score=-17.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WBFSYGWYvrDG for ; Thu, 7 Nov 2019 15:45:52 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913281200C4 for ; Thu, 7 Nov 2019 15:45:52 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id k11so1176433ual.10 for ; Thu, 07 Nov 2019 15:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vl8D8LJ+mJ6sTTukIDxoWLzVG8uGFBLJrxChrlqC7CY=; b=A3juhuJXWAbEncu39op1kg3pSrrKrkC2uJ5m/bwymkV1XwbUMz/xvXUoUnVGnwb8II sRhmPo3hBvV8ameAFS7KCWJBDgKFjkSl/B7n9jdEDUksfhkKDdelvjXZkzh7pN9PtQVW I0yYcmpbA0v668HkwwxQFr+I1W30zaOByqbz1/8FWGSfD7hqM69rwqA6yUtpFGfOvGas WvLlG35h58JpW72YeZ3G5JX3TMfYD/Q8Hq1FenjCQ6QOxSK3Umsf2gx2TZhlm/+SPcOM T/H0qCRkSIlm3bPbYGxxPGXvTKSi4aXImCuC5UIsBsKZJ87XzEfxu7l3ioWPJZklRbY1 DkDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vl8D8LJ+mJ6sTTukIDxoWLzVG8uGFBLJrxChrlqC7CY=; b=gLMERBtRKmoS3cHX5pFTuH6SnjQwhHIb5rVbP3Paa0T0mY9MzxA6vZnVJWpmGInqai r0il40uQKMDkAyuy/H+iJyeBQ69iytGCuwmt7BA+nBqIvQuL1dRlkSkhioHLZ9oatblz PxwNuzW7DDFb7N677cLCO2rBxNwgFxm9/LjpZhmQqAS5Tlv0maXqXlXxx/U5xoWG2GEV W5ZlKjmLV+3VJ6k5FWZ7JA6ddiidvyZEAsPIlgJxvAo8DgRtL178So2oSo3tt37Y9oVd c1wOnsHeUtq9RBkl920t0JXpQuVnXs4/jluGvu32kUOlXzvKQ4846YpafidhJ0rPsLyv vH6A== X-Gm-Message-State: APjAAAV18VSN6EFt5C2UwCMn2CRKdasrDmw8XtmIcsU3h8nJqmCCDLyL ZFS35lUlO56pB5V01ftpuyMHhWUi+wXDqexqJ61YD8fGWQ== X-Google-Smtp-Source: APXvYqwnTIloGo1yJOnrMV+NJf81LLZYbqCy7S/iAcLvFAjWS3aTduwHKbf+nXXJIigmVguWOZq6s/YWgZK0o/S/kRk= X-Received: by 2002:ab0:55c8:: with SMTP id w8mr4116682uaa.66.1573170350672; Thu, 07 Nov 2019 15:45:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Thu, 7 Nov 2019 15:45:37 -0800 Message-ID: To: "Weist, Bill" Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/related; boundary="000000000000ed10f80596ca432d" Archived-At: Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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, 07 Nov 2019 23:45:56 -0000 --000000000000ed10f80596ca432d Content-Type: multipart/alternative; boundary="000000000000ed10f50596ca432c" --000000000000ed10f50596ca432c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, its for checking whether a custodian made changes, but the changes its checking for are the core of the message (to use the DKIM wording), the same as DKIM. If the core of the message was unchanged, then ARC is unnecessary. The utility of ARC is to pinpoint where the core was changed, so the receiver can make a judgement as to how to handle the message. Brandon On Thu, Nov 7, 2019 at 8:45 AM Weist, Bill wrote: > Thank you both for replying. There are two instances where I have > identified ARC signatures consistently failing: > > > > Case 1: An intermediary SMTP system receives an email on behalf of a > recipient system whereby the =E2=80=9Cfrom=E2=80=9D field is required to = be changed for the > email to reply as desired by the recipient system. (example: > William.Weist@gmail.com rewritten to William.Weist@iqvia.com) > > > > Case 2: An Intermediary SMTP system receives an email on behalf of the > recipient system whereby the =E2=80=9Csubject=E2=80=9D field is required = to by changed for > the email to be categorized as desired by the recipient system. (example: > =E2=80=9CRE: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D modified t= o: =E2=80=9CRFC > Correspondence: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D) > > > > As Kurt pointed out below, the ARC signature is NOT intended to be > validated by hops >1 step away. However, I did not think this was the ca= se > and that ARC was specifically supposed to validate each custodian where > DKIM would be broken by the cases listed above. > > > > As differentiated from DKIM, the RFC reads as if ARC is designed to > validate the =E2=80=9Ccustodian=E2=80=9D and NOT the =E2=80=9Csender=E2= =80=9D therefore, =E2=80=9CFrom=E2=80=9D and > =E2=80=9CSubject=E2=80=9D would not be as desirable as say =E2=80=9CX-Rec= eived=E2=80=9D, > =E2=80=9CX-Google-Smtp-Source=E2=80=9D, and =E2=80=9CX-Gm-Message-State= =E2=80=9D in the case of Brandon=E2=80=99s > email to which I am replying. > > > > It is my suggestion that for ARC to be a valuable addition to DKIM, it > needs to focus on the =E2=80=9Ccustodian=E2=80=9D and not the =E2=80=9Cse= nder=E2=80=9D. > > > > Thank you both for your time and attention. > > -Bill > > > > *From:* Brandon Long > *Sent:* Wednesday, November 6, 2019 12:43 PM > *To:* Kurt Andersen (b) > *Cc:* Weist, Bill ; dmarc@ietf.org > *Subject:* Re: [dmarc-ietf] Question regarding RFC 8617 > > > > This email originated from outside of the organization. > > > > What's more, the point of including Subject and other mutable headers is > the same as it is for DKIM, those are the headers which are important to > the receiver, so they should be validated. > > As Kurt points out, the point of ARC is to acknowledge these changes hop > to hop, and the Arc Seal proves who did the change, the question becomes = do > you believe > > the person who changed it wasn't malicious. > > > > Brandon > > > > On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) wrote= : > > The choice of which headers are included in the signed set is strictly up > to the domain administrators who implement the signing practices. Also, t= he > AMS is only relevant for the next receiver, it is not intended to be > validated by hops >1 step away from the domain which adds that instance s= o > I don't see how mutability would matter. > > > > --Kurt Andersen > > > > On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill > wrote: > > DOI: 10.17487/RFC8617 > > > > The inclusion of the address headers in the signature, and possibly the > Subject, is an issue: > > > > ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D > microsoft.com > ; > s=3Darcselector9901; h=3DFrom:Date:Subject:Message-ID:Content-Type:MIME-V= ersion:X-MS-Exchange-SenderADCheck; > bh=3D; > > > > If a downstream server needs to modify either of these two values, the > signature check fails. > > > > It is my understanding that the Authenticated Received Check signature is > to validate the chain of possession. As such, in my opinion, the signatu= re > should only include immutable references. > > > > In my opinion, there is value in NOT requiring headers to be stripped by > downstream servers, thus maintaining the custody chain from origination t= o > destination. > > > > Thank you for your time and attention, > > > > *William M. Weist* > > *Enterprise Architect I =E2=80=93 Global Messaging =E2=80=93 Mobile and P= resence* > > CIO Team =E2=80=93 End User Computing > > *[image: IQVIA logo_96dpi_100pxheight]* > > Learn more > > about IQVIA=E2=84=A2 > > > > 400 Campus Drive > > Collegeville, PA 19426 > > USA > > > > O: +1 610 244 2646 <(610)%20244-2646> | M: +1 484 904 8244 > <(484)%20904-8244> > > > > > > ________________________________________ > *IMPORTANT* - PLEASE READ: This electronic message, including its > attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY > PRIVILEGED or PROTECTED information and is intended for the authorized > recipient of the sender. If you are not the intended recipient, you are > hereby notified that any use, disclosure, copying, or distribution of thi= s > message or any of the information included in it is unauthorized and > strictly prohibited. If you have received this message in error, please > immediately notify the sender by reply e-mail and permanently delete this > message and its attachments, along with any copies thereof, from all > locations received (e.g., computer, mobile device, etc.). To the extent > permitted by law, we may monitor electronic communications for the purpos= es > of ensuring compliance with our legal and regulatory obligations and > internal policies. We may also collect email traffic headers for analyzin= g > patterns of network traffic and managing client relationships. For furthe= r > information see: https://www.iqvia.com/about-us/privacy/privacy-policy > .. > Thank you. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > --000000000000ed10f50596ca432c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, its for checking whether=C2=A0a custodian made c= hanges, but the changes its checking for are the core of the message (to us= e the DKIM wording), the same as DKIM.

If the core of the message wa= s unchanged, then ARC is unnecessary.=C2=A0 The utility of ARC is to pinpoi= nt where the core was changed, so the receiver can make a=C2=A0
j= udgement as to how to handle the message.

Brandon<= /div>
O= n Thu, Nov 7, 2019 at 8:45 AM Weist, Bill <William.Weist@iqvia.com> wrote:

Thank you both for replying.=C2=A0 There are two ins= tances where I have identified ARC signatures consistently failing:<= u>

=C2=A0

Case 1:=C2=A0 An intermediary SMTP system receives a= n email on behalf of a recipient system whereby the =E2=80=9Cfrom=E2=80=9D = field is required to be changed for the email to reply as desired by the re= cipient system.=C2=A0 (example: William.Weist@gmail.com rewritten to William.We= ist@iqvia.com)

=C2=A0

Case 2: An Intermediary SMTP system receives an emai= l on behalf of the recipient system whereby the =E2=80=9Csubject=E2=80=9D f= ield is required to by changed for the email to be categorized as desired b= y the recipient system. (example: =E2=80=9CRE: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D modified to:=C2=A0 =E2=80=9CRFC Corre= spondence: [dmarc-ietf] Question regarding RFC 8617=E2=80=9D)=

=C2=A0

As Kurt pointed out below, the ARC signature is NOT = intended to be validated by hops >1 step away.=C2=A0 However, I did not = think this was the case and that ARC was specifically supposed to validate = each custodian where DKIM would be broken by the cases listed above.

=C2=A0

As differentiated from DKIM, the RFC reads as if ARC= is designed to validate the =E2=80=9Ccustodian=E2=80=9D and NOT the =E2=80= =9Csender=E2=80=9D therefore, =E2=80=9CFrom=E2=80=9D and =E2=80=9CSubject= =E2=80=9D would not be as desirable as say =E2=80=9CX-Received=E2=80=9D, = =E2=80=9CX-Google-Smtp-Source=E2=80=9D, and =E2=80=9CX-Gm-Message-State=E2= =80=9D in the case of Brandon=E2=80=99s email to which I am replying.

=C2=A0

It is my suggestion that for ARC to be a valuable ad= dition to DKIM, it needs to focus on the =E2=80=9Ccustodian=E2=80=9D and no= t the =E2=80=9Csender=E2=80=9D.

=C2=A0

Thank you both for your time and attention.

-Bill

=C2=A0

From: Brandon Long <blong@google.com>
Sent: Wednesday, November 6, 2019 12:43 PM
To: Kurt Andersen (b) <kboth@drkurt.com>
Cc: Weist, Bill <William.Weist@iqvia.com>; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Question regarding RFC 8617<= /p>

=C2=A0

This email originated from outside of the organ= ization.

=C2=A0

What's more, the point of including Subject and = other mutable headers is the same as it is for DKIM, those are the headers = which are important to the receiver, so they should be validated.=C2=A0=C2= =A0

As Kurt points out, the point of ARC is to acknowledge these changes hop to= hop, and the Arc Seal proves who did the change, the question=C2=A0becomes= do you believe

the person who changed it wasn't malicious.

=C2=A0

Brandon

=C2=A0

On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b) <= ;kboth@drkurt.com= > wrote:

The choice of which headers are included in the sign= ed set is strictly up to the domain administrators who implement the signin= g practices. Also, the AMS is only relevant for the next receiver, it is no= t intended to be validated by hops >1 step away from the domain which adds that instance so I don't se= e how mutability would matter.

=C2=A0

--Kurt Andersen

=C2=A0

On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill <William.Weist@iqvia= .com> wrote:

DOI:=C2=A0 10.17487/RFC8617

=C2=A0

The inclusion of the address headers in the signatur= e, and possibly the Subject, is an issue:

=C2=A0

ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c=3Dre= laxed/relaxed; d=3Dmicrosoft.com; s=3Darcselector9901; h=3DFrom:Dat= e:Subject:Message-ID:Content-Type:= MIME-Version:X-MS-Exchange-SenderADCheck; bh=3D;

=C2=A0

If a downstream server needs to modify either of the= se two values, the signature check fails.

=C2=A0

It is my understanding that the Authenticated Receiv= ed Check signature is to validate the chain of possession.=C2=A0 As such, i= n my opinion, the signature should only include immutable references.

=C2=A0

In my opinion, there is value in NOT requiring heade= rs to be stripped by downstream servers, thus maintaining the custody chain= from origination to destination.

=C2=A0

Thank you for your time and attention,=

=C2=A0

William M. Weist

Enterprise Archite= ct I =E2=80=93 Global Messaging =E2=80=93 Mobile and Presence=

CIO Team =E2=80=93 En= d User Computing

3D"IQVIA

Learn more about IQVIA=E2=84=A2

=C2=A0

400 Campus Drive

Collegeville, PA 19426=

USA

=C2=A0

O: +1 610 244 2646 | M:= +1 484 904 8244

=C2=A0



________________________________________
IMPORTANT - PLEASE READ: This = electronic message, including its attachments, is CONFIDENTIAL and may cont= ain PROPRIETARY or LEGALLY PRIVILEGED or PROTECTED information and is intended for the authorized recipient of the sender. If= you are not the intended recipient, you are hereby notified that any use, = disclosure, copying, or distribution of this message or any of the informat= ion included in it is unauthorized and strictly prohibited. If you have received this message in error, pleas= e immediately notify the sender by reply e-mail and permanently delete this= message and its attachments, along with any copies thereof, from all locat= ions received (e.g., computer, mobile device, etc.). To the extent permitted by law, we may monitor electronic c= ommunications for the purposes of ensuring compliance with our legal and re= gulatory obligations and internal policies. We may also collect email traff= ic headers for analyzing patterns of network traffic and managing client relationships. For further informat= ion see: https://www.iqvia.com/about-us/privacy/privacy-policy.. Thank you.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.i= etf.org/mailman/listinfo/dmarc

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://w= ww.ietf.org/mailman/listinfo/dmarc

--000000000000ed10f50596ca432c-- --000000000000ed10f80596ca432d Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <16e4828a81e4ce8e91> X-Attachment-Id: 16e4828a81e4ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABkANUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKo65qB0jRr++CeabW3knCE43bVLYz74ry/wn8dp9e+I2k+HLzQhYafqnh+11W31QXQdTdSo0j2 hXAwVjQuGz8wDcDHOkacppuPQzlUjFpPqevUV8/2v7Tl3qOj398NAttJtj4lTQ7DUNUvtlobZ4PO jvbhwv7pJB8qLzlnjBI3cekeIPHV/wCEfhXqHinVrSxN3Y2j3UsNreF7Zgp+8spUfKV+bJHFaSoV INKS3IjWhO9nsdxRXnd18a/D8fjKy0e31TS7uxfSrzVLvUIb9HW1WB4V+YLnAPmnkkY2981tR/E7 w1NpMupJqe+2inFtIqwSmZJSu4IYtu8Er8wG3kc9KzdOas2i1Ug20nsdVRXl/if456T4XuJr+aSO 88NrpEGpR3lkGleRpbjyVCgcFeh/OrVn8adDXxvqWhahqNnZBfsJsGferzC5QlN+RhNzqVXOMkY6 1XsZ2vb+v6Ye0he1z0aivK/jN8ZLj4X32i2lvp1teT6lFcPbpdXPlNeTRBCtlbqAS9xKGYouMYjb JrqvG/j+08EeDbzX5oJL0wmOCOytmUyzXMkixRwAk7QzSOqckAE80vZTtF2+LYPaRV79NzqqK81h +IHijw3rWg2vjHRNOs7PWpDaxXmkXklwtpciN5BFNvjXKlY3AkHG4AEDIrY1j4naJa+Gzqdhqum3 Hm6b/ats1zcmKGW2yo84uFbCfOvzYP3hQ6U7pW3Eqke52VFci3xX8JL4hl0I69af2vFM1tJaBiWW ZYhMYjxjzPLO8J94ryARXJyfHux1jwTceIvDwtriFdJ1K/jh1B3hmaS1AIUR7fmQ5+ZgRtyvBzwK lN9AdSEd2etUVytn8R9Ck1Gy0q41GGLV51jBtgGwsjxh1jLY2hypyFJ3Ec4q94c8a6L4skuU0i/j vjbkeYY1YDBJAZSQAykqRuXI4PPFS4yWrRfNF9TcorkZfix4St4dUmn1y2tYNLiae7luN0SRRK21 pNzAAoG4LDIB6mlHxV8KG4sof7ahEl4I2i3I4GHYrGWJGE3sCF3Y3ds0ezn2Fzx7nW0Vy3iz4n+F vA90ltr2uWmmXDW7XYjmY7vJVgrykAHCKWXcx4XIyRTr74meF9N16HRbnW7WHUpWiRYSxIDSf6pW YDarP/CpILds0ck7XsHPHa509FczD8SvC89xY26a7Yme+gubm2i80B5Yrdglw4B5xGxAb0JxW7pu o22r6fa31nMtxaXUSzQzJ910YAqw9iCDScWt0VdPYs0UUVIwooooAKKKKAKOt6edX0e/sQ/lG6t5 IPMxnbuUrnHfGa8l1f8AZ2OreHJ9OHiO4sLo2OlWltqFnCFmtns1dHkXJP8ArY5HQjsGPNeyTTJb wvLIwSNFLMzdAAMk15pa/tKfDi9mMdv4nt5nAzhY5DwO/wB2uyhDESTlRi2lvZXt6nHXq4anKMa8 0m9ru1/QlX4Y6noLa8/h3UdNgi1O9gn+wajp5ntxbx2kdv8AZ8K6nH7oPu/DBqHSvgsul/BW68Aj U1b7VHcK9wtsFhiM0rSskUO4hIl3FUjydqgDJxVz/hf/AID/AOhgi/79Sf8AxNcv4i/bM+DnhLUf sGseOLPTrsoJBFPFKpZT/EPl5H0q1DFS91Qb26dvkJSw17qS69e+5ufET4G6f48vFkjuI9IiGl3N gVtrVQS8ksEiSEjGQrQfd7hjyKz2+C2rtbidNZsrLUpNSjvL1bO3nSG/hSFo1hnYzGVgpbzAQ4GV VSCuQdP4X/tJfDX4zaxd6V4N8WWWu6jawfapbaDcHWLdt34YDI3YH4itf4ufFC0+EfhI69e2U9/C J44BDbkBstnnJ44ANOEMVKpHDKL5nok139Sa1TDUaU8TUlaMdW+1vQ4+z/Z9nsfB76NDr6iddF/s uK6Nn8qyC5a4SUpv5XJAKZ6DrW7rPwnuvEFvr7XeqQpeaxJpk0zw2pCI9o6OdoLE4Yrxk/LnvXoV ndLe2cFwgISVFkAbrgjI/nXN/ED4neHfhjpYvtf1BbVX4ihQF5piOoRBycdz0HesoOvWqKEFeTey Wt/6RpUlQw9J1KslGKWrbsrHJ/E/4K3Pj7X7rULfV4bRL7To9Nm+02zSy2XlytIlzZuHXyZgXJ3c 5KRn+DBuad8F4F+D6eAtR1KSdIV/dataxLDc+akvmxXTZ3KbgSBZGbGGcE7QDivPP+Gyba63T6f4 E8Q32nA/8fSIMY9eAR+tehfC/wDaD8JfFaX7Lp11JZaqF3HT75dkpA67Tkq+O+Dkd69Otl+Y4elz VKbUY69Hb1tt8zxsPm+U4qt7OlVTlLbdX9L2v8jP1D4X+NvEHiXw5e634w0u/wBM0WZp1sYdGeE3 ErRtF5rsJyN6pI+0AbQzbsHAxk2v7PerN4dbRr7xRBNbW/h5/Ddk8Wn7HWHzY3SaQ7zuk2xqpA2q TyAM4r2LxBqw0HQ9Q1I2812LO3kuPs9uMySbFLbVHcnGBXn/AOzv8fdF/aK+H8fibSLWfTJFma3u 9Nu3RprWQYIDFSQQylWBHUNXnKdZwdSPwq3Redv1PZdOip8r3d+r8v8AgF64+FZmu5JxqKqX8Tx+ IseR/diWPys577Pve+MVg/8ACjb+40GTSrrX4Xjj0/WNMtZY7Iqyw3rKVLguQzx7cEjAb0FewU2R 1jVmZgqqMlmOAB61gq01szZ0oPdHkNr8Bfsni6e/+2WV5pN3qVvrFxa3trJJItzFDHGpjIlCAboY 3DMjMpBAOCNu/wDDX4caj4J1HV57jV4pLO7VEh0uwgaG0gZWctMkbu+x33gMqkJ8gIUEnOD8Cf2k tG+P2s+MrbQtKv4NP8PXi2iapOUa3vwd3zxlSSB8ucNztZW6NVj4gftCaZ8PfjL4D+Hl1pN9d3vi 0SmG+gZBDbbOm8E7juII+UHHeumUcQ5OjJa2202Sv+XzMIOgoqrF6N7+r/zMCP8AZx1G7+1HVfFP 9pTSaXcaWbqa2Z5bhZbiKbzZS0hG791t2oFT5jgdAOg8TfBP+3PGmpasl1ZyafrEtrLqFnf28s3z QBQvl7ZVXkKv31baRuHpXqtLWH1ipe9zVUaa0scR4o+HP/CSeINS1I3qwi88P3Gh+WYQ23zX3eZn POP7veuVm+BupY1LTLfxBDF4e1i7s77UYjYBrrzYI4UKxS7sKri3j+8rMnzbTyu2n+0F+1b4X/Z4 1fw1p2s2l3qNxq8u6VbNkH2G1DBXuZNxGVBYfKPmOGIHBr2i2uYry3ingkWWGVA6SIchlIyCD6EV f76lCM2rJ7fIm1KpJxvqt9e54l4h/ZpbWbzxFcQeJprGTUNSjurFktEJ061dg19aoc8rclpizHkG QY+4K9ttreO1gjhiQRxRqERFGAqgYA/KuA1/4rS+FdYNvqOjk2H25rI3ltciQx/6P5yyOhUEAkpH gZIZx2ya6zwfrz+KPC+lavJZyadJe20c72crh3gZlBKMRwSp4JHHFTUdWUU57fL+un9XKh7OMmo7 /wBf5/1Y2KKKK5jcKKKKACub+IGr+IND8M3F34Z0WPX9WR0CWMk4hDKWAY7j6DnFdJXnPxY+FzeP ms7tvF+teGIbCKQyDS5/LRwcEs/uAP1NdeFVN1o+1do+abXpZWeu2hw411lh5+wTcraWaT9U2mtN 9Uzm9O+IXxburdzefDi1tn3Y8v7crZGOuQfrWWsXitJDIvwg0FXJzuHlg1x+mX3gGaNLe3+M+s3D In3t7liBxknFXv8AijP+iva1/wB9P/hXs1qbp1JJU+W/Tlmvzdzw8PUVWlFurztdeam9fVK33HTe Z4x/6JJof/fUdct8QF8fLpUd1pfwD8L+I9QjkVBbXckKYjJ+YqxB6enen/8AFGf9Fe1r/vp/8K5b 4mXXw5t/CNymr/HzXvDdrM6RjUIZ2jkRt2QFYqeTjH0rOnH317v4T/RnS5X0Uvxh/keifs23nj6b xJq6eKvgtoPwzsfsiGK/0q6ikkuZN5/dFUXO0DnJPWrP7av/ACRg/wDYRg/k1cP+x/L8Pj401seE fjxrvxTvXsFMml6reebHBGJP9cqlRzkhcg9xXcftq/8AJGT/ANhGD+TV04KPLnFFWt70ejX/AKVd nJnF/wCw8Um9eSXZ9PJL8j2TTr2LTfCltdztthgskldvRVjBP6Cvm/4K+Dx8f/FurfEjxdD9r09b k2+madNzEFU5GV7qoI+XoW3E54x77q+ny6t8L7uyg5muNIaJB6sYcCvMP2Mtatr34QR6ch23mm3k 0VxERhlLNvUkfQ4/A1lhZSoYLEV6Xx3jG/VRd7/e0kTjoQxWZ4TDV9afLOVukpR5Ur97JtnusVvH bwrFEixxqMBEUBQPTArwz9or4K2mqaHdeL/DkA0zxVpQ+2CazGxrhU5OcfxgDKt14wcgmvd84rnP iLr1p4a8C69qV64S2t7KVmz3JUgKPckgfjXl4HEVsPiITo73Wnfyfe57OZ4XD4vCTp4j4Um7/wAt luuzRj/BP4gN8TvhppGuTBReSIYboKML5yHa5A9CRn8a+UbFv+GPP2ypLJj9l+HXxGO+LtFbXTPw OvG2V8f7s6dkr3j9jfS7jTfgrZyTqyi6u5541YY+TdtBHsdpNH7YnwOHxz+DOpafawh/EGm51HSm zgmZFO6PPYSIWT6kHtXp1fY4bMK2G/5dNuPpro/kzzcHKvjMqw2Kl/FUYy9XbX/wJHuNfM37dnxm ufh/8M4fCmgPI/i7xhJ/ZtnDbtiVYWIWV1wcgtuWNT/ekB7Gtr9j349xfFr4HwX2tXQi13w8hsdZ af5WBjXKzMMcbkAY+jBh2rxr9ne1uP2qv2nPEPxj1OJm8J+G3+weHYZR8rOAdjgeoRmkPH3plHVK 5cPhvYVpzrrSnv5vovn+R6NfEKtShCi9am3kur+X5n0n+zX8GbX4E/CPRvDMaxm/VPtOozxjAmun AMh+g4UeiqBXg/7S/wDyfJ+z1/22/wDQmr7Jr42/aX/5Pk/Z6/7bf+hNU4KpKriJzm7txn/6SzTF QjToRhFaJx/9KR9k1R13WrLw3ot9qupXKWmn2MD3NxPI2FjjRSzMT7AVer49/bw+IWp+Jbjw18D/ AAlJv8Q+LbiM3uw58q13fKr89GKs7A9Uicd64sNQeIqqnsur7LqzpxFb2FJz3fTzfRHl/wAN/hBd ftyeIPij8S/EXm2Wn3cUmk+FxIDiCRAfLcj+IRgjI6F5ZQegr2j9gX4sX2veB9S+G/iXfB4s8ETG xkhmbLtbBiqc99jK0ee4VT/FXq/w61P4cfB3wTpPgzT/ABTodtBo8ItWWTUIlkaQf6xn+b77NuJz 3NfMn7RV5a/BD48+Ffj94PurfVPDOpT/ANl+JP7NlWWNm2gMSVyMtGoPrvgjH8Ve37X6854a1o/Y 8rLRfNfieOqX1PkxF7y+3536/wDbr/A+6WtYZGLNEjHOcsoPOMZ/SnxxrGoVFCKOiqMAVX0vU7XW tNtb+ynW5s7qJZoZozlXRgCrA+hBq3XzfkfQhRRRSAKKKKACkZQ6lWAZSMEEZBpaKAPHfifp2reF 7zTx4O+F+jeJIpUc3EziKExMCMLg4zkEnPtWHb3njaS3jaT4RaLHIygsmY/lPcV77j2owPSvR+uX pxg4Jtdbyu/XW33JHlLAuNWVRVWk/s2jZenu3+9s8G+0eMv+iS6L/wCQ68/8feIvizHqaWmk/s4e H/ENhGgdri7uYI18w9lU5PA7nFfXO0elG0elTHFKLu6af/gX6M2eFb/5eP8A8l/yPnv9m/UPH934 k1dfFnwX0P4aWItEMWoaXcxPJcSbz+6KoM4A5zmr37ZttNdfBtkghknf+0IPljQsedwHT3IH417t j2pGUMMEZHvWlDG+xxcMUoL3WnZN9PN3ZjjMD9bwVTBufxpq9l18lYpaEjR6Lp6spVlt4wVIwQdo 4r568dfC7xf8J/H1147+G8X9oWV5l9S0HGdxJy21eNyk5bj5lJOMgkV9KUlThcbPCVJSik4y0aez X9bMWPy2lj6cYTbjKDvGS0cX3X6p6M+TfHn7U1n4u8D6r4bv/C/iLQ9avrYwDyF/1cnbk7WK56jG SM1yHw8h8bftERad4I1LVxY+H/DyxtfM24XUq5IXIbl3GCoJwF4JycV9utbxu4do1Zh0YqCa5zS/ ht4f0fxpqXiuz09Ydc1GMRXNwHbDKMfw5wCcDJHXAr3aOcYXD0ZwoUOSW8XfmtLbra2nrrbQ+XxH D2NxWIhUxWK9pD4ZK3JeG9nyt3963RaXV0bejaRaaBpVppthAttZWsSwwwp0VFGAKuGlor5Jtyd3 ufexiopRirJH5rftUfCnxh8J/jHreneAIbhdD+LMQsmtbaBmj+0NJ+9hJUfuwS5l3f3Wm7CvvD4K fC3T/gz8M9D8J6fh1sYf38+MG4nb5pZT7s5Jrt2QMQSASDkcdKdXoYjGzxFKFKS238+iv6LQ4aGD hQqyqJ77eXV29XqFfHv7SGn3dz+29+z5NDZ3M0Ki4LTRwO8abSSdzAYXAPcivsKmlAzBiASOhx0r nw9b2E3O19GvvTX6nRWpKtFRb6p/c7lPWtTXRdHvtQkilnS1gknaKFSzuFUttUDqTjgV8ffsS+Dt W+KXjjxZ8ffF1pNDqGszyWui29zGymC34DsobBACqkQ452Ow4evs6kVFjUBQAB2AxTp13SpThFay sr+XVfPQmpRVSpCcnpHW3n3+R80ah/wTr+CWpaleXsmgX8ct1cSXMixanMq75HLtgbuBuY8ds11N r+yB8PtB+Dfin4d6Dp0mn6XrzNcyzSzNNKt1tURzBnzgoUQjH92vcKSrljcTJJSqN2830EsLQTbU Fd76dz5U/YF8WeI7bwn4k+GniqwurfVPA179hS4khdYmhYsVjV2ABCkHbjP7toz3r6spoUKxIGCe vvTqyxFVV6sqiVr/ANP8S6FN0aapt3sFFFFc5uFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//Z --000000000000ed10f80596ca432d-- From nobody Thu Nov 7 16:13:14 2019 Return-Path: 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 74B13120147 for ; Thu, 7 Nov 2019 16:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Km-5X1Kgv9ZN for ; Thu, 7 Nov 2019 16:13:10 -0800 (PST) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B294C1200C4 for ; Thu, 7 Nov 2019 16:13:10 -0800 (PST) Received: by mail-oi1-x243.google.com with SMTP id a14so3714030oid.5 for ; Thu, 07 Nov 2019 16:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oCyF5onVtgxWkaw+tVgf2ltwR0VaiakJbYrZo1lAI8o=; b=CRGtmN9wctEHvgbVtEdjn2PY3yT+GBfgKy0+k0RjrMTGug6y7qpxlb0+hOI0bYBJ/4 tiEMb+bTV4vQXPm9uRAIJAEoFOAuM0AgEHn6mSbPPHJJvD7n1o0dCMqfRyGvzqUfzIsH pdHbDMM9Ai9BZh1pzlPAgVhqB76RMuZG8gzxRTPE7YIDGaJCLaI4MclZMLvweEHRiEMY 10Ir1dJ1ZTESDH6/hSzkhTiy5bHqcKc3ssUHx1D47LEtNFq+E6fhf7lr9/aaOR7HJBlK GDWYEGiCFTiYcW0cD70Al71K6qkR7WQcH7dt8PwoYfUP9sd2c7IPQ7NgXSlzXRQhO/gc kapA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oCyF5onVtgxWkaw+tVgf2ltwR0VaiakJbYrZo1lAI8o=; b=CssKCuWKvlG7O3/UEpaVbhJJKAaEcZqTavGBtmU1oVoyHONi6Js0nbKtKVA5SFTwE9 /97ygB7Lk4QpEUL8d3DnXjoRHQy4NQw1SUO3I7rLv0bUlCmjqMH7EKfkZd5bH4tjoOh0 D+A46v/acZ2cqa1MpEmd0IDX7dbCcgsVW5v2FPv36dXk6CtzAEjFo3qo2voI7tw4CkjA WNhD+ffzTuAR2RGjOd6UkNq8hFTcx7ABB1YU1L1zGNOgGp2byzVtBhVDyk4rrHpFCVlH VY/lu4H3rVy+9PWmzRUBZzPCRAFA+5j8A5shvaipIsgpH5hdgZERe9Hjusj2JdRMdDBp DkeQ== X-Gm-Message-State: APjAAAWgh+YwfFGXfq05cz5a2Re/+eoj+MtVwzj46ulMfM9SJuvxeZ/G 5hZHD/2UfgSeaHc6/hEO1S0KIqgw X-Google-Smtp-Source: APXvYqyU0ULNc36X2UKLQTBbEF+031sJC2Yh+7RlQBc9t7p07BS6DWostBV38SqQlb/CRwMzGsiPJw== X-Received: by 2002:aca:3e8a:: with SMTP id l132mr6082441oia.146.1573171989939; Thu, 07 Nov 2019 16:13:09 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:911f:9579:419e:7fa6? ([2600:1700:a3a0:4c80:911f:9579:419e:7fa6]) by smtp.gmail.com with ESMTPSA id c23sm1088872oiy.20.2019.11.07.16.13.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 16:13:09 -0800 (PST) To: Brandon Long Cc: Brandon Long , "Kurt Andersen (b)" , "dmarc@ietf.org" , "Weist, Bill" References: <2b25082c-34b2-93f6-9412-6b669652e317@gmail.com> From: Dave Crocker Message-ID: <5bad5d4a-af9a-3da8-fb7d-3d70b6917be0@gmail.com> Date: Thu, 7 Nov 2019 16:13:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Question regarding RFC 8617 X-BeenThere: dmarc@ietf.org 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, 08 Nov 2019 00:13:13 -0000 On 11/7/2019 3:16 PM, Brandon Long wrote: > > > On Thu, Nov 7, 2019 at 9:28 AM Dave Crocker > wrote: > > On 11/6/2019 9:43 AM, Brandon Long wrote: > > What's more, the point of including Subject and other mutable > headers is > > the same as it is for DKIM, those are the headers which are > important to > > the receiver, so they should be validated. > > > This being a technical list, I'm going to get picky and note that DKIM > does not 'validate' those fields. > > There is a derivative data integrity benefit, between signing and > validated, for such fields, but that is quite different from any claim > that the contents of those fields are 'valid'. > > Some signing sites have much more stringent uses of DKIM than are > provided by the standard.  That's fine, of course, but it has > nothing to > do with the standard.  Hence any receive-side reliance on such signer > data validation is outside the DKIM standard. > > > I should have said "covered by the signature". > > And I think they are important to both the sender and receiver, your DKIM > RFC calls them "core to the message content" and so the "core of the > message is valid"... which is different than validated, of course. yeah. really unfortunate language. over the course of different DKIM docs, I kept finding language that needed to be /much/ better. Only some of it now is. That's not one of them, since the context was of that bit of text was meant to assert transit integrity rather than data 'validity'. sigh. At least there is some comfort that that section makes clear it's concern is replay protection, rather than semantic validity. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Nov 10 22:30:21 2019 Return-Path: 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 761481201E4 for ; Sun, 10 Nov 2019 22:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cxKZf2ETdwX5 for ; Sun, 10 Nov 2019 22:30:17 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43367120168 for ; Sun, 10 Nov 2019 22:30:17 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id k15so8018193vsp.2 for ; Sun, 10 Nov 2019 22:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=geligwlPwGeMtP1aqFYnnFWmiq4FB7s51hALEnfiEf0=; b=Bs4zjxkZnmnjda7fpoAEwFfht9ZI30w9bxuAlbMDQNJqdsD1pYAO3YicTI+ndOSrti m+iZPrjXfAG9hMTAAeL0SjL8EGX2xzPwNcgX1B08GDLU1+BuO4MIWGujqROo4bgSE8bx af/AwgeFEfkqrdYsawwwm+Axk4xylix28fmPXpg/yG/EoBxNqPUxLkBIZLBr/kSMwgzL AMJkZIJba6ckncTgysdcbESMPRgS9Cw3xlc2DThZDeTNZX5IWu9XMErCVASy3rmdgVQB mS8UWx8grR7AjXfZOfZ8qddPtAyTbQhSuTOJ0uGTO7/Ru0w+M4jOylI67qHRFHHdMTmi PiHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=geligwlPwGeMtP1aqFYnnFWmiq4FB7s51hALEnfiEf0=; b=Jc0vP6tgkm4Ix8GpAFLKNTXdFYwZUjryd40fpXWrHNzSdwQG4BTUSuumoW5pI3/t0u /k/QjHlMxQqq9rZwDE3YYkEAtunOXyJrOltJCWNj0xL4wTNrswW/6RF2Gnxxmyrcg+/C 5xa6gA3rTR85JFasatv8DwN1p3dJO0LEhDmnXJADtnBbP3pNwD+y1YylADBia3w9BT8D NTSX2w6O7QdB1oLYKxHzMevIj/gltBj/bp0RvtvrPdxd/bKJoFOk0gMjANAxvJ+OCnUV UZd3wPKam5h3X+O6PBCWQjTcVrSjHkIl6zHYGmiXdnSJYaW52DTvwe7vX5m/Co0kGyzb ex1A== X-Gm-Message-State: APjAAAXuk7j6GW6MiUkqpjsguozp72OO1BPUciSV8LJPvdhQJcE0I3GI glWYGz7dX87hNI8lhzx8HMCTfEuRjgKVYfM7NlsgOQ== X-Google-Smtp-Source: APXvYqyAOGDz/bh/SWiUhemGevZQEwSRqedZGgPRpm3smknigdI0AODC7JZDMdWrSKju1EOOrAn4UhMYHAFsK1ibELs= X-Received: by 2002:a05:6102:109e:: with SMTP id s30mr19053993vsr.175.1573453816110; Sun, 10 Nov 2019 22:30:16 -0800 (PST) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 10 Nov 2019 22:30:05 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c7a26b05970c43d4" Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 06:30:19 -0000 --000000000000c7a26b05970c43d4 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote: > On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote: > > > >> If the definition of ptype smtp were "a parameter of the SMTP session > used > >> to relay the message" it would be perfect. I'd propose that > policy.iprev > >> be deprecated and smtp.remote-ip used instead>> > > > > Given that RFC8601 was published just last month, it'll probably be a > while > > before this happens. > > Wouldn't an accepted erratum be enough to change the wording in the IANA > page? > That's not what the RFC Editor erratum system is for. The document reflects what the WG intended to publish at the time, so this isn't an erratum, it's a new change to the specification. About the new ptype, a reviewer suggested to also use it to report whether > the > query supported DNSSEC. No DNSWL that I know supports it. However, I know > some DKIM filters report that feature either as a comment or as a reason > in the > dkim= methodspec. Using the new ptype might make that clearer. Consider: > > Authentication-Results: example.com; > dkim=pass dns.sec=yes header.i=@example.org header.b=j5aQ3SJv > Are there any MTAs that would take a different action based on this information? -MSK --000000000000c7a26b05970c43d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 7:54 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote: >
>> If the definition of ptype smtp were "a parameter of the SMTP= session used
>> to relay the message" it would be perfect.=C2=A0 I'd prop= ose that policy.iprev
>> be deprecated and smtp.remote-ip used instead>>
>
> Given that RFC8601 was published just last month, it'll probably b= e a while
> before this happens.

Wouldn't an accepted erratum be enough to change the wording in the IAN= A page?

That's not what the RFC Edi= tor erratum system is for.=C2=A0 The document reflects what the WG intended= to publish at the time, so this isn't an erratum, it's a new chang= e to the specification.

About the new ptype, a reviewer suggested to also use it to report whether = the
query supported DNSSEC.=C2=A0 No DNSWL that I know supports it.=C2=A0 Howev= er, I know
some DKIM filters report that feature either as a comment or as a reason in= the
dkim=3D methodspec.=C2=A0 Using the new ptype might make that clearer.=C2= =A0 Consider:

=C2=A0 =C2=A0 Authentication-Results: example.com;
=C2=A0 =C2=A0 =C2=A0 dkim=3Dpass dns.sec=3Dyes header.i=3D@example.org header.= b=3Dj5aQ3SJv

Are there any MTAs that wo= uld take a different action based on this information?

-MSK
--000000000000c7a26b05970c43d4-- From nobody Sun Nov 10 23:34:56 2019 Return-Path: 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 E3FB91201DE for ; Sun, 10 Nov 2019 23:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PXe1ykh5Rts8 for ; Sun, 10 Nov 2019 23:34:51 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DB8120154 for ; Sun, 10 Nov 2019 23:34:51 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id a143so8087848vsd.9 for ; Sun, 10 Nov 2019 23:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sh2XMOldISsmZS4KFUSmGx1NQJq63WsFvywILYzo46k=; b=kwKFooy6cPZ6yywr/XOe0ckXwr8l6nNGOyOBWu7pogp3XVGHOMYRtIwI8mvX+GVg5I pbbUTQiHPqeHHeJ5C+y4hDg7LwNO+b4swYaHxCKtHb4Zt7UVjGpwkqLLu358GVTqhdLi o2avlNh1uiUzgrFFGkItiacskgmgHIboXeRbfhjlIzQWUrB0eV9xcusRAoiNWnPO0kL5 pFv1oSxcXftfFvNp56ForfH2YZ9ALAD1gzzhOjt+ujxZcrVb+EIaPjwHAOrpL/lr1jbu +LlAVvJ2qK5gPPY1+M2VE9odNY6AXafhVKKwLm86aKK8jFpTQnCVXNrd59uM+yCrVmXg 2c0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sh2XMOldISsmZS4KFUSmGx1NQJq63WsFvywILYzo46k=; b=fPk8hMbgJu3stGrp56A1ndR6caIxUnYrs7fMJfQwnAM5lUHavdjy7tXI6M+87bOHkm J5/411KzYlEdtpZdkL8WXN5ZELAPLO4YveJflQ1LrmjGQ5CJjnt92WDVK8cOccHgLjPm j/kL8+2LTzf5gcuyOQ/YIVzHXHQtHxAUT+f5+GQtzU71/NnmHK8PKT3WCjFsStOo3VfU HzkikJi0vqjOGrmMN5bmjICdyDMruxTQmkuGICGU3tNBzhq7AtVKQwvrTwSNvUC1n9WN YUqeWk1J/NJGfwn3eTUXhK0PMWhrXZfhFOLnlpaHO0jqhhSIY+tZEC87byRU659CEr2B kUjA== X-Gm-Message-State: APjAAAUI0VSAw5lKr8YPpLsbKBCbI0V1JtVCOBGOJVdKdOgERg11QWgl 5Ob8GaVUlSmfTyVO+xoz0ZZjYO1/jU/x2lbaz50= X-Google-Smtp-Source: APXvYqx7zkE9BP4TpIE5c4yl+207mqUvcIikx95vg64gq4GQIGf2kcrkU0wFZ1kLk6MspboaqrsklJ7iSRJzErUMzZs= X-Received: by 2002:a67:d198:: with SMTP id w24mr19103214vsi.13.1573457690422; Sun, 10 Nov 2019 23:34:50 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> In-Reply-To: <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> From: "Murray S. Kucherawy" Date: Sun, 10 Nov 2019 23:34:39 -0800 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b4f16005970d2af2" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 07:34:54 -0000 --000000000000b4f16005970d2af2 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker wrote: > > 1. The change to DMARC should be limited to permitting the query for the > > organization domain to be anywhere in the DNS tree, including a TLD. > > Within DMARC this would not look like 'extra' mechanism. > > > > 2. The mechanism that processes that query should be cast strictly as a > > PSL enhancement, independent of DMARC. > > > Trying to refine things further: > > > DMARC does not care about the PSL. > > What DMARC cares about is the Organizational Domain (OD), as a > fallback when no DMARC record is found at the desired domain name. > > That is, PSL is literally outside the scope of DMARC. > > At the least, therefore, the DMARC specification should define a > distinct interface to the outside functionality that tells DMARC where > the OD is, which will return what suffix of the full domain name is the > OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix > > The PSL-related side of that interface should be a separate > specification, so that changes to its behavior -- such as has been > happening with the introduction of ODs that are TLDs or are otherwise > 'above' where DMARC has been guessing the OD to be -- are isolated from > DMARC. > > The current problems are that DMARC has embedded too much detail > about the PSL world, yet DMARC has no involvement in that world. The > current proposal embeds assumptions of PSL knowledge further, rather > than separating PSL knowledge out. > We (the chairs) fully agree with all of this. What we -- I in particular -- have been struggling with is to find a path forward so the PSD experiment can still take place without being blocked by the need to first go back and overhaul RFC 7489 as you've described here, separating DMARC and the OD determination. Because that'll take months. We are perhaps in the fortuitous position in our charter now that our very next work item is to take up the task of reopening DMARC itself, and the separation of function Dave is espousing could be made into a reality during that work. Given this, we suggest that the PSD draft be allowed to proceed as Experimental, but with appropriate preamble text added to its Introduction explaining the deficiency Dave has identified. So the order of operations becomes: * add text to the PSD draft making it clear that what it's describing is an experiment whose outcome will be taken only as feedback to the revision of the standard (i.e., this is not intended to be the final form of anything), and it is not intended to be deployed outside of the experiment's participants; * publish the experiment with those cautions and allow the experiment to begin * while the experiment is running, spin up the work on two new standards track documents, in line with our charter: a) DMARC, with PSL references replaced by the abstract notion of the OD that's determined in some non-specific way, as Dave suggests b) a PSL document that satisfies the abstract notion of OD in the DMARC document, also as Dave suggests * when the experiment completes, either augment (b) if it's still in development, or publish a revision to it, based on what the experiment has revealed Can this be made to work? Honestly, the experiment could start anyway without an RFC published, but a formal record of the experiment and its caveats doesn't strike me as a wrong thing to do. -MSK --000000000000b4f16005970d2af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 5, 2019 at 1:22 PM Dave Crock= er <dcrocker@gmail.com> wro= te:
> 1. The change to DMARC should be limited to permitting = the query for the
> organization domain to be anywhere in the DNS tree, including a TLD. <= br> > Within DMARC this would not look like 'extra' mechanism.
>
> 2. The mechanism that processes that query should be cast strictly as = a
> PSL enhancement, independent of DMARC.


Trying to refine things further:


=C2=A0 =C2=A0 DMARC does not care about the PSL.

=C2=A0 =C2=A0 What DMARC cares about is the Organizational Domain (OD), as = a
fallback when no DMARC record is found at the desired domain name.

=C2=A0 =C2=A0 That is, PSL is literally outside the scope of DMARC.

=C2=A0 =C2=A0 At the least, therefore, the DMARC specification should defin= e a
distinct interface to the outside functionality that tells DMARC where
the OD is, which will return what suffix of the full domain name is the OD --=C2=A0 eg, getOrgDomain(full-domain) -> org-domain-suffix

=C2=A0 =C2=A0 The PSL-related side of that interface should be a separate <= br> specification, so that changes to its behavior -- such as has been
happening with the introduction of ODs that are TLDs or are otherwise
'above' where DMARC has been guessing the OD to be -- are isolated = from
DMARC.

=C2=A0 =C2=A0 The current problems are that DMARC has embedded too much det= ail
about the PSL world, yet DMARC has no involvement in that world. The
current proposal embeds assumptions of PSL knowledge further, rather
than separating PSL knowledge out.

We (= the chairs) fully agree with all of this.=C2=A0 What we -- I in particular = -- have been struggling with is to find a path forward so the PSD experimen= t can still take place without being blocked by the need to first go back a= nd overhaul RFC 7489 as you've described here, separating DMARC and the= OD determination.=C2=A0 Because that'll take months.
We are perhaps in the fortuitous position in our charter now th= at our very next work item is to take up the task of reopening DMARC itself= , and the separation of function Dave is espousing could be made into a rea= lity during that work.=C2=A0 Given this, we suggest that the PSD draft be a= llowed to proceed as Experimental, but with appropriate preamble text added= to its Introduction explaining the deficiency Dave has identified.=C2=A0 S= o the order of operations becomes:

* add text to the PSD draft makin= g it clear that what it's describing is an experiment whose outcome wil= l be taken only as feedback to the revision of the standard (i.e., this is = not intended to be the final form of anything), and it is not intended to b= e deployed outside of the experiment's participants;
* publis= h the experiment with those cautions and allow the experiment to begin
* while the experiment is running, spin up the work on two new standa= rds track documents, in line with our charter:
=C2=A0 a) DMARC, with PSL= references replaced by the abstract notion of the OD that's determined= in some non-specific way, as Dave suggests
=C2=A0 b) a PSL d= ocument that satisfies the abstract notion of OD in the DMARC document, als= o as Dave suggests
* when the experiment completes, either au= gment (b) if it's still in development, or publish a revision to it, ba= sed on what the experiment has revealed

Can th= is be made to work?

Honestly, the experiment could= start anyway without an RFC published, but a formal record of the experime= nt and its caveats doesn't strike me as a wrong thing to do.
<= div>
-MSK

--000000000000b4f16005970d2af2-- From nobody Sun Nov 10 23:48:16 2019 Return-Path: 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 82720120844 for ; Sun, 10 Nov 2019 23:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eaRYWyr2jbGA for ; Sun, 10 Nov 2019 23:48:13 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8780C12083B for ; Sun, 10 Nov 2019 23:48:13 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id u79so2940595vke.4 for ; Sun, 10 Nov 2019 23:48:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sfkq57pnt47iaJFB02j0M0T7kjl4EcB+x3nDfmPjcmM=; b=HRB+aGntlR5SI+Nhw9w12rMt4jOTwJ78XjeR+Hwbz/0UlLiAZ7Qb+Uk3awpvf5cw2C SBOO0JYXHxFJ/lInM/v9aquF627v1yXuGk9LsTyJ2ttfwmCtVwEBAxvIVFKwM50VEbzd 74PFlRt6UCGi2zTZmtztIE20sX69STalO8hQi1ZOxEiFr+TmdV0QpRVJJjt2xy/WfMR1 CtrOU6slSASrJVVEm68H5WxL9o9bAGSqRyOXzb9+ALV84kT0z68ic2HbKMF0SgeZ0ZGF l8sFWeEFEPezoDrkHJSprR6JxRdKo3uCl56Ih6CA7LBKZKLfjbKU7w76sa/Wo6mTogd9 y72w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sfkq57pnt47iaJFB02j0M0T7kjl4EcB+x3nDfmPjcmM=; b=Io5BlgSz2ysCjJF+Fjp5jUVvHYFcwhQDH2Fe6MsJh5/XvvRiMGckN7P8N45lg3hgyc W/8s8irl3utct75S+rNn/4adaF4lDm5xQ+HjZ0aX8anQ7XzQ3GK6MnZlmuTJtr8ctMCe hG86mVqp6e0M8WNPHFh4sX4H9OsuNh33kjWA64cSbXwu3uBp5sojKhfQLQXSfawIBgkD p0ciRwqZrhEfuHWT9kVrKHV26kZ0vKRHkUYwnTs5SIScH9YbS6R97PaGGMbOmPIde97Y rm0LcDtIUfpKzZU8FoLOhjAMStL/a8SAPNo9MWhYBr6AVlzIYtlI/4bC6OOkMXEMiHCd QIUg== X-Gm-Message-State: APjAAAXw/Raa9GDZ4Us+N32m9PWea6iql1V2ZhnDBNKdsypOlmzF6Adf FoiM58eRL/YVj7I2cPby6WiMCBBgYgDHuA2tbRs= X-Google-Smtp-Source: APXvYqwv4OL3hYyODUOuklpUHkia1b9Nowo+B1EeskL/G9K84psUsJxAOevYyn5mmldXgDhqBo/WzrmA8+pS6Lfinec= X-Received: by 2002:a1f:2a82:: with SMTP id q124mr17087963vkq.8.1573458492506; Sun, 10 Nov 2019 23:48:12 -0800 (PST) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Sun, 10 Nov 2019 23:48:01 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000083c8b605970d5a1a" Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 07:48:15 -0000 --00000000000083c8b605970d5a1a Content-Type: text/plain; charset="UTF-8" On Sun, Nov 10, 2019 at 10:30 PM Murray S. Kucherawy wrote: > On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote: > >> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote: >> > >> >> If the definition of ptype smtp were "a parameter of the SMTP session >> used >> >> to relay the message" it would be perfect. I'd propose that >> policy.iprev >> >> be deprecated and smtp.remote-ip used instead>> >> > >> > Given that RFC8601 was published just last month, it'll probably be a >> while >> > before this happens. >> >> Wouldn't an accepted erratum be enough to change the wording in the IANA >> page? >> > > That's not what the RFC Editor erratum system is for. The document > reflects what the WG intended to publish at the time, so this isn't an > erratum, it's a new change to the specification. > Just to be clear: The policy for changes to that registry is "Expert Review", but since the action that put it there was a document with IETF consensus, I'm pretty hesitant about just approving this change based on a formal request. I'd rather at least see some consensus discussion about it, or even better, a revision/update to RFC8601. -MSK, this time as DE --00000000000083c8b605970d5a1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 10, 2019 at 10:30 PM Murray S= . Kucherawy <superuser@gmail.com<= /a>> wrote:
On Wed 07/Aug/2019= 17:16:29 +0200 Murray S. Kucherawy wrote:
>
>> If the definition of ptype smtp were "a parameter of the SMTP= session used
>> to relay the message" it would be perfect.=C2=A0 I'd prop= ose that policy.iprev
>> be deprecated and smtp.remote-ip used instead>>
>
> Given that RFC8601 was published just last month, it'll probably b= e a while
> before this happens.

Wouldn't an accepted erratum be enough to change the wording in the IAN= A page?

That's not what the RFC Edi= tor erratum system is for.=C2=A0 The document reflects what the WG intended= to publish at the time, so this isn't an erratum, it's a new chang= e to the specification.

J= ust to be clear: The policy for changes to that registry is "Expert Re= view", but since the action that put it there was a document with IETF= consensus, I'm pretty hesitant about just approving this change based = on a formal request.=C2=A0 I'd rather at least see some consensus discu= ssion about it, or even better, a revision/update to RFC8601.
-MSK, this time as DE
--00000000000083c8b605970d5a1a-- From nobody Mon Nov 11 00:16:31 2019 Return-Path: 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 B676512083D for ; Mon, 11 Nov 2019 00:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 TtBrfBZyapFA for ; Mon, 11 Nov 2019 00:16:28 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBC2120826 for ; Mon, 11 Nov 2019 00:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573460185; bh=a+4s+gtzoM7T3KqY9FBI91RVhEaD3/poJveQdL2+a/Y=; l=849; h=To:References:From:Date:In-Reply-To; b=CQQRX7gx/FHbfb2YICO3teqkYpnKz1HYh6Y/lZYlx+7YKNWtunOqP418wq46aln2y fGofNZwO8sfdSrOjCUqTTrU+T1y3QCygnEcCSPZRvGjsdiq/UrGXP6WvpT7O1x7kz8 yHEA9Kuh/r+4Mqw2lR2bXN+yMv1x9xYOTLIrfnI8h/pPaGR9KvQOeDEL3kZGV Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC07E.000000005DC918D9.000077FC; Mon, 11 Nov 2019 09:16:25 +0100 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Mon, 11 Nov 2019 09:16:24 +0100 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=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 08:16:30 -0000 On Mon 11/Nov/2019 07:30:05 +0100 Murray S. Kucherawy wrote: > On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote: > >> About the new ptype, a reviewer suggested to also use it to report >> whether the query supported DNSSEC. No DNSWL that I know supports it. >> However, I know some DKIM filters report that feature either as a comment >> or as a reason in the dkim= methodspec. Using the new ptype might make >> that clearer. Consider:>> >> Authentication-Results: example.com; >> dkim=pass dns.sec=yes header.i=@example.org header.b=j5aQ3SJv >> > > Are there any MTAs that would take a different action based on this > information? Nobody cares about DNSSEC, until they fall victim to DNS hijacking attacks. If the property is there, it may be easier to retrofit a fix in that case. Best Ale -- From nobody Mon Nov 11 00:29:08 2019 Return-Path: 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 0E358120826 for ; Mon, 11 Nov 2019 00:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=iE+g5Hnm; dkim=pass (2048-bit key) header.d=kitterman.com header.b=qmUcSs8O 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 i5SehodD_H0w for ; Mon, 11 Nov 2019 00:29:06 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7461612004D for ; Mon, 11 Nov 2019 00:29:06 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 6B2C1F8064C; Mon, 11 Nov 2019 03:29:05 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1573460945; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=cYKRITtBpIXZYkuP+bJqgzi+dEW/AFcIFdDM4RJSews=; b=iE+g5HnmPek5BQ2sVasEl6TBhESt7TFZrYiETBIo07+HlXUfXkv5G1GF 9xmePM/hHQ8CXPugU+Jd6ZzfRo/+Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1573460945; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=cYKRITtBpIXZYkuP+bJqgzi+dEW/AFcIFdDM4RJSews=; b=qmUcSs8O+/4M7P7nxYvwoZyBsDy7A7anHQqLIk/PA6qyToFnYj4MBbaT J2mtAiNNl4vo8+GLEUelXwa+/xboyzMKYZKCLM+8yGofOcVTPTi7Lz2wDJ qykoQoFnTsODZFGpu0yRqPEiSYJOgzWpdseBbDSehXKSH9YTFXC/ZDGY9R eOCGQprbB97zsfkRYwi3FcudZdkvy+5EELFKcSJ19edxsWNUIPI8aWWGgO ysUCjifolxXxXYrQKaYphPnPrCrGsiPMVQf7WtKw0MYET9Bcztrc7LhBbA 6HhqywVnAmjCpzHxwfsSnRVzTmx3fGwKnrMZxtnVu/DsVAeHS/qpeQ== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 39528F805BD; Mon, 11 Nov 2019 03:29:05 -0500 (EST) Date: Mon, 11 Nov 2019 08:29:02 +0000 In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 08:29:08 -0000 On November 11, 2019 7:34:39 AM UTC, "Murray S=2E Kucherawy" wrote: >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker wrote: > >> > 1=2E The change to DMARC should be limited to permitting the query >for the >> > organization domain to be anywhere in the DNS tree, including a >TLD=2E >> > Within DMARC this would not look like 'extra' mechanism=2E >> > >> > 2=2E The mechanism that processes that query should be cast strictly >as a >> > PSL enhancement, independent of DMARC=2E >> >> >> Trying to refine things further: >> >> >> DMARC does not care about the PSL=2E >> >> What DMARC cares about is the Organizational Domain (OD), as a >> fallback when no DMARC record is found at the desired domain name=2E >> >> That is, PSL is literally outside the scope of DMARC=2E >> >> At the least, therefore, the DMARC specification should define a >> distinct interface to the outside functionality that tells DMARC >where >> the OD is, which will return what suffix of the full domain name is >the >> OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix >> >> The PSL-related side of that interface should be a separate >> specification, so that changes to its behavior -- such as has been >> happening with the introduction of ODs that are TLDs or are otherwise >> 'above' where DMARC has been guessing the OD to be -- are isolated >from >> DMARC=2E >> >> The current problems are that DMARC has embedded too much detail >> about the PSL world, yet DMARC has no involvement in that world=2E The >> current proposal embeds assumptions of PSL knowledge further, rather >> than separating PSL knowledge out=2E >> > >We (the chairs) fully agree with all of this=2E What we -- I in >particular >-- have been struggling with is to find a path forward so the PSD >experiment can still take place without being blocked by the need to >first >go back and overhaul RFC 7489 as you've described here, separating >DMARC >and the OD determination=2E Because that'll take months=2E > >We are perhaps in the fortuitous position in our charter now that our >very >next work item is to take up the task of reopening DMARC itself, and >the >separation of function Dave is espousing could be made into a reality >during that work=2E Given this, we suggest that the PSD draft be allowed >to >proceed as Experimental, but with appropriate preamble text added to >its >Introduction explaining the deficiency Dave has identified=2E So the >order >of operations becomes: > >* add text to the PSD draft making it clear that what it's describing >is an >experiment whose outcome will be taken only as feedback to the revision >of >the standard (i=2Ee=2E, this is not intended to be the final form of >anything), >and it is not intended to be deployed outside of the experiment's >participants; >* publish the experiment with those cautions and allow the experiment >to >begin >* while the experiment is running, spin up the work on two new >standards >track documents, in line with our charter: >a) DMARC, with PSL references replaced by the abstract notion of the OD >that's determined in some non-specific way, as Dave suggests >b) a PSL document that satisfies the abstract notion of OD in the DMARC >document, also as Dave suggests >* when the experiment completes, either augment (b) if it's still in >development, or publish a revision to it, based on what the experiment >has >revealed > >Can this be made to work? > >Honestly, the experiment could start anyway without an RFC published, >but a >formal record of the experiment and its caveats doesn't strike me as a >wrong thing to do=2E The current revision of the PSD DMARC draft makes no reference to the PSL = in the body of the draft (it only comes up in Appendix A and C)=2E It se= ems like an odd choice to continue to insist PSD DMARC is specifically tied= to the PSL when the text indicating so has been removed (Dave's email was = two months ago and things have changed in the interim)=2E I don't think the proposed note says anything the status of experimental s= houldn't already communicate=2E Given the current state of the draft, I do= n't think it's necessary to have such a note=2E Scott K From nobody Mon Nov 11 01:21:37 2019 Return-Path: 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 83343120897 for ; Mon, 11 Nov 2019 01:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.org 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 Y7yjV-1Yk7BU for ; Mon, 11 Nov 2019 01:21:35 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 F3C1D120829 for ; Mon, 11 Nov 2019 01:21:34 -0800 (PST) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1573464095; b=CzkSvgGmexJPEVr0UrmQD8bSl0r/pQZDbLX6cVevtA5YSSkW8gqxt2nJoWwWoNus4lDbs5dJW8 ymaegYNTism9NPEhbvKabvIDbMHM11E6LnYVSwX0WHs4SJvBjcLitXzVw/rTvsaqQMdJurqv+L +huNVu+nHte/7qf1tGEvm8Q=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1573464095; bh=I4B3jmXC5Sr2hjmAKGGJS/XwHSdJT5qWDUPIsd6rKTI=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=AVQrpZfvHghAfni0+b0YGu6NdVRf7DW940CqtZ1flfO7xXB1h9utLNBzRaHPw9xzJbwrthOzt7 QtYDaQ37Zi5f0zkVUO+/Qub/THQXL5q+vX4RBcAVxVrlVbx22MWOneP7LE4+Lw6voZ/jF1QQew xluhHbXjUkxX2Pefp+YziJg=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=GgmBs1fAcXYc8oWGen701DG7/LCGWhRNN2zoYALDWow=; b=A w6dOppcMZDjtqUMByocgH+MDBzSgstA7WSjf4TN1dXFYo1J3ny/981xCsgJGgS454OH1ug8U9PXi1 laFlPkfNjytSEJgMQf4kUCD6nKcuRxxk9U582RtzQ3cn7mufxvHn/ObfyjZLDLQbetoH6CTBSoHZc Chm8Col22dGtkIOE=; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) by wizmail.org (Exim 4.92.131) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1iU5t6-0002oQ-H5 for dmarc@ietf.org (return-path ); Mon, 11 Nov 2019 09:21:32 +0000 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: Date: Mon, 11 Nov 2019 09:21:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 09:21:36 -0000 On 11/11/2019 06:30, Murray S. Kucherawy wrote: >> Authentication-Results: example.com; >> dkim=pass dns.sec=yes header.i=@example.org header.b=j5aQ3SJv >> > > Are there any MTAs that would take a different action based on this > information? For Exim it would be a fairly simple bit of additional ACL, in the config file. -- Cheers, Jeremy From nobody Mon Nov 11 01:23:11 2019 Return-Path: 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 61BDF120897 for ; Mon, 11 Nov 2019 01:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 vdRIWEvOqWQv for ; Mon, 11 Nov 2019 01:23:08 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9C91201DB for ; Mon, 11 Nov 2019 01:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573464186; bh=55SRjIEcGIdwEjqEVH4hgLwVmLY+AjppfzAkeohhSxc=; l=3150; h=To:Cc:References:From:Date:In-Reply-To; b=BEA7Jyp/71yDkozfy4+AsTgjzrr1YUtTFYH4bCPSmNkPlMJnzk2mXjkM7D8mEBs3B adqhohz71PU8ZNbKjlgU3tleC8xtOXT3xwr6T8dJY/b/RD/BhEl4Twdszzixonyv9w hSALzuffvn8CyvrrHQ2PgPba7Nf5rOeyaR1GCsZrJqFiLiKS/YSNwHJFXOqJP Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC076.000000005DC92879.00007FB2; Mon, 11 Nov 2019 10:23:05 +0100 To: "Murray S. Kucherawy" , "Kurt Andersen (b)" Cc: IETF DMARC WG References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Mon, 11 Nov 2019 10:23:05 +0100 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=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype? X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 09:23:09 -0000 On Mon 11/Nov/2019 08:48:01 +0100 Murray S. Kucherawy wrote: > On Sun, Nov 10, 2019 at 10:30 PM Murray S. Kucherawy wrote: >> On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote: >>> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote: >>>> >>>>> On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote: >>>>> >>>>>> Note that RFC8617 section 10.2 ( >>>>>> https://tools.ietf.org/html/rfc8617#section-10.2) does add in an >>>>>> smtp.remote-ip method item. >>>>> If the definition of ptype smtp were "a parameter of the SMTP >>>>> session used to relay the message" it would be perfect. I'd propose >>>>> that policy.iprev be deprecated and smtp.remote-ip used instead >>>> Given that RFC8601 was published just last month, it'll probably be a >>>> while before this happens. >>> Wouldn't an accepted erratum be enough to change the wording in the IANA >>> page? >> That's not what the RFC Editor erratum system is for. The document >> reflects what the WG intended to publish at the time, so this isn't an >> erratum, it's a new change to the specification. Yes, as DE you could change it without an erratum. However, an erratum would serve as a justification to any reader who followed the definitions and noticed a mismatch. The ptype table was introduced by rfc7401, Section 3: +--------+-------------+----------------------------------------+ | smtp | RFC 7001 | The property being reported is a | | | Section 2.2 | parameter to an SMTP command used to | | | | relay the message. | +--------+-------------+----------------------------------------+ Rfc7601 and rfc8601, both in Section 6.4 claim to be a complete restatement of the definition and rules for this registry, and direct IANA to update this registry to show their Section 2.3. However, IANA still has the above definition. > Just to be clear: The policy for changes to that registry is "Expert > Review", but since the action that put it there was a document with IETF > consensus, I'm pretty hesitant about just approving this change based on a > formal request. I'd rather at least see some consensus discussion about > it, or even better, a revision/update to RFC8601. > > -MSK, this time as DE I think this group would make a better use of its time by discussing rfc7489bis than rfc8601bis. If group consensus can be enough for the time being, an erratum can also serve as a reminder. So I ask for it: Does the WG agree to an erratum as follows: TYPE: technical SECTION: 2.3 ORIGINAL TEXT: smtp: Indicates information that was extracted from an SMTP command that was used to relay the message. The "property" indicates which SMTP command included the extracted content as a parameter. CORRECTED TEXT: smtp: Indicates information that was extracted from a parameter of the SMTP session that was used to relay the message. The "property" indicates which parameter included the extracted content. NOTES This change makes the "smtp" type consistent with the definition of smtp.remote-ip given in rfc8617 Section 10.2. ? TIA for answers Ale -- From nobody Mon Nov 11 01:58:16 2019 Return-Path: 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 69C22120831 for ; Mon, 11 Nov 2019 01:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iqLJzZkXvHvg for ; Mon, 11 Nov 2019 01:58:11 -0800 (PST) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF7E12080F for ; Mon, 11 Nov 2019 01:58:11 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id 22so10969725oip.7 for ; Mon, 11 Nov 2019 01:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LU8lDXrrvKzOIMjZBnK+3E56vYwZ7FipYbHafJbBT3w=; b=IxN4G0izAnXg5t+JiAofJPSLJNpJJdM/fg2E70vUvGxy7MjZ6+1bD6k4t7Y7p2EWpz xasw6MSirmQMAOgeUu8rqmTyPbiGCHkk3Vo+m+lyYtrPTCNQJ6jiK/3x+pFscUeoQBL/ Sln/9pT2BiUbpekXHrTzgb6Q/Gsikz1I2r42/1949AGYs+veBqrMofaLfrp/CKfqXH0T Gmc3V/hMA1At81418J7qBtjND9ndX0nSQEkbB/ELGW+uZxhXHliQ+RMtmQdcDrdnUDxE ZBiuZYN3Vawf1tnTI+MvRPOqZbShQKGuvuV5gK15nFfVKtNMsP8WZwq/1NKOfN2UMgfn Nl3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LU8lDXrrvKzOIMjZBnK+3E56vYwZ7FipYbHafJbBT3w=; b=q867SKS7wcIFHjv1QXahGSflxL1vRgmzW3meQm4BAW2q0JRZiIGLnFryuVud5sw9p2 toSlOtteQW4X189pANmsZO74EY5QHx7HpGTqT2jJGKoWbBMierWslXJ6Y8qv6bvd8pJG Of1GHpu7EDfDHOkN+jm9fC9bDwAJ2UDhJOQ+qmsWqD3c6ZbS6f/RkLHZCeCphsz5CZlz 6c1siVTeqhiN2E/Hx6PlONTVaZCg6ordaClymdudD6lZRQa8Iw5Nrf/+/tPcHCbalnXI 6q+/E/2eIjvDHi5DVUKE8cnrVFSHTyD8w9y0gyFYVlW5N2MolG4nW0oYPJpQbJmtrTkj QW3w== X-Gm-Message-State: APjAAAVG3DPSBzRwxOTtiNz6XnjZxbyLPDr7nf4bL16IbWMbK0numOvv NZ/ir+7j+ew+h541oJZLsUGySVDs8Jm2vttyTZk= X-Google-Smtp-Source: APXvYqzm6JoUV/YaUZHuoOW1SL6TwDh2My4jobOSRgFJqzaBkBy/7IQ5dE9PrbjhyqhXxuO/N1NkI7MXM81MSV/gUbU= X-Received: by 2002:aca:a842:: with SMTP id r63mr22191715oie.118.1573466290986; Mon, 11 Nov 2019 01:58:10 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> In-Reply-To: <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> From: Tim Wicinski Date: Mon, 11 Nov 2019 04:58:00 -0500 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005722da05970f2b72" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 09:58:14 -0000 --0000000000005722da05970f2b72 Content-Type: text/plain; charset="UTF-8" Scott PSD DMARC does talk about organizational domains which from the original DMARC spec (section 3.2) does say 'Acquire a "public suffix" list' The addition of the preamble text shouldn't move the document in either direction. I do feel anything which helps focus us on moving forward on DMARC-bis is a good thing. The WG should be able to start writing the PSL document right away. Murray and I will be in Singapore if anyone wishes to speak their mind. thanks Tim On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman wrote: > > > On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" < > superuser@gmail.com> wrote: > >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker wrote: > > > >> > 1. The change to DMARC should be limited to permitting the query > >for the > >> > organization domain to be anywhere in the DNS tree, including a > >TLD. > >> > Within DMARC this would not look like 'extra' mechanism. > >> > > >> > 2. The mechanism that processes that query should be cast strictly > >as a > >> > PSL enhancement, independent of DMARC. > >> > >> > >> Trying to refine things further: > >> > >> > >> DMARC does not care about the PSL. > >> > >> What DMARC cares about is the Organizational Domain (OD), as a > >> fallback when no DMARC record is found at the desired domain name. > >> > >> That is, PSL is literally outside the scope of DMARC. > >> > >> At the least, therefore, the DMARC specification should define a > >> distinct interface to the outside functionality that tells DMARC > >where > >> the OD is, which will return what suffix of the full domain name is > >the > >> OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix > >> > >> The PSL-related side of that interface should be a separate > >> specification, so that changes to its behavior -- such as has been > >> happening with the introduction of ODs that are TLDs or are otherwise > >> 'above' where DMARC has been guessing the OD to be -- are isolated > >from > >> DMARC. > >> > >> The current problems are that DMARC has embedded too much detail > >> about the PSL world, yet DMARC has no involvement in that world. The > >> current proposal embeds assumptions of PSL knowledge further, rather > >> than separating PSL knowledge out. > >> > > > >We (the chairs) fully agree with all of this. What we -- I in > >particular > >-- have been struggling with is to find a path forward so the PSD > >experiment can still take place without being blocked by the need to > >first > >go back and overhaul RFC 7489 as you've described here, separating > >DMARC > >and the OD determination. Because that'll take months. > > > >We are perhaps in the fortuitous position in our charter now that our > >very > >next work item is to take up the task of reopening DMARC itself, and > >the > >separation of function Dave is espousing could be made into a reality > >during that work. Given this, we suggest that the PSD draft be allowed > >to > >proceed as Experimental, but with appropriate preamble text added to > >its > >Introduction explaining the deficiency Dave has identified. So the > >order > >of operations becomes: > > > >* add text to the PSD draft making it clear that what it's describing > >is an > >experiment whose outcome will be taken only as feedback to the revision > >of > >the standard (i.e., this is not intended to be the final form of > >anything), > >and it is not intended to be deployed outside of the experiment's > >participants; > >* publish the experiment with those cautions and allow the experiment > >to > >begin > >* while the experiment is running, spin up the work on two new > >standards > >track documents, in line with our charter: > >a) DMARC, with PSL references replaced by the abstract notion of the OD > >that's determined in some non-specific way, as Dave suggests > >b) a PSL document that satisfies the abstract notion of OD in the DMARC > >document, also as Dave suggests > >* when the experiment completes, either augment (b) if it's still in > >development, or publish a revision to it, based on what the experiment > >has > >revealed > > > >Can this be made to work? > > > >Honestly, the experiment could start anyway without an RFC published, > >but a > >formal record of the experiment and its caveats doesn't strike me as a > >wrong thing to do. > > The current revision of the PSD DMARC draft makes no reference to the PSL > in the body of the draft (it only comes up in Appendix A and C). It > seems like an odd choice to continue to insist PSD DMARC is specifically > tied to the PSL when the text indicating so has been removed (Dave's email > was two months ago and things have changed in the interim). > > I don't think the proposed note says anything the status of experimental > shouldn't already communicate. Given the current state of the draft, I > don't think it's necessary to have such a note. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000005722da05970f2b72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scott

PSD DMARC does t= alk about organizational domains which from the original DMARC spec (sectio= n 3.2)=C2=A0
does say 'Acquire a "public suffix" li= st'

The addition of the preamble text shouldn&= #39;t move the document in either direction.=C2=A0
I do feel anyt= hing which helps focus us on moving forward on DMARC-bis is a good thing.= =C2=A0
The WG should be able to start writing the PSL document ri= ght away.=C2=A0

Murray and I will be in Singapore = if anyone wishes to speak their mind.

thanks
=
Tim




=
On Mon, No= v 11, 2019 at 3:29 AM Scott Kitterman <sklist@kitterman.com> wrote:


On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <superuser@gmail.com<= /a>> wrote:
>On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <dcrocker@gmail.com> wrote:
>
>> > 1. The change to DMARC should be limited to permitting the qu= ery
>for the
>> > organization domain to be anywhere in the DNS tree, including= a
>TLD.
>> > Within DMARC this would not look like 'extra' mechani= sm.
>> >
>> > 2. The mechanism that processes that query should be cast str= ictly
>as a
>> > PSL enhancement, independent of DMARC.
>>
>>
>> Trying to refine things further:
>>
>>
>>=C2=A0 =C2=A0 =C2=A0DMARC does not care about the PSL.
>>
>>=C2=A0 =C2=A0 =C2=A0What DMARC cares about is the Organizational Do= main (OD), as a
>> fallback when no DMARC record is found at the desired domain name.=
>>
>>=C2=A0 =C2=A0 =C2=A0That is, PSL is literally outside the scope of = DMARC.
>>
>>=C2=A0 =C2=A0 =C2=A0At the least, therefore, the DMARC specificatio= n should define a
>> distinct interface to the outside functionality that tells DMARC >where
>> the OD is, which will return what suffix of the full domain name i= s
>the
>> OD --=C2=A0 eg, getOrgDomain(full-domain) -> org-domain-suffix<= br> >>
>>=C2=A0 =C2=A0 =C2=A0The PSL-related side of that interface should b= e a separate
>> specification, so that changes to its behavior -- such as has been=
>> happening with the introduction of ODs that are TLDs or are otherw= ise
>> 'above' where DMARC has been guessing the OD to be -- are = isolated
>from
>> DMARC.
>>
>>=C2=A0 =C2=A0 =C2=A0The current problems are that DMARC has embedde= d too much detail
>> about the PSL world, yet DMARC has no involvement in that world. T= he
>> current proposal embeds assumptions of PSL knowledge further, rath= er
>> than separating PSL knowledge out.
>>
>
>We (the chairs) fully agree with all of this.=C2=A0 What we -- I in
>particular
>-- have been struggling with is to find a path forward so the PSD
>experiment can still take place without being blocked by the need to >first
>go back and overhaul RFC 7489 as you've described here, separating<= br> >DMARC
>and the OD determination.=C2=A0 Because that'll take months.
>
>We are perhaps in the fortuitous position in our charter now that our >very
>next work item is to take up the task of reopening DMARC itself, and >the
>separation of function Dave is espousing could be made into a reality >during that work.=C2=A0 Given this, we suggest that the PSD draft be al= lowed
>to
>proceed as Experimental, but with appropriate preamble text added to >its
>Introduction explaining the deficiency Dave has identified.=C2=A0 So th= e
>order
>of operations becomes:
>
>* add text to the PSD draft making it clear that what it's describi= ng
>is an
>experiment whose outcome will be taken only as feedback to the revision=
>of
>the standard (i.e., this is not intended to be the final form of
>anything),
>and it is not intended to be deployed outside of the experiment's >participants;
>* publish the experiment with those cautions and allow the experiment >to
>begin
>* while the experiment is running, spin up the work on two new
>standards
>track documents, in line with our charter:
>a) DMARC, with PSL references replaced by the abstract notion of the OD=
>that's determined in some non-specific way, as Dave suggests
>b) a PSL document that satisfies the abstract notion of OD in the DMARC=
>document, also as Dave suggests
>* when the experiment completes, either augment (b) if it's still i= n
>development, or publish a revision to it, based on what the experiment<= br> >has
>revealed
>
>Can this be made to work?
>
>Honestly, the experiment could start anyway without an RFC published, >but a
>formal record of the experiment and its caveats doesn't strike me a= s a
>wrong thing to do.

The current revision of the PSD DMARC draft makes no reference to the PSL i= n the body of the draft (it only comes up in Appendix A and C).=C2=A0 =C2= =A0 It seems like an odd choice to continue to insist PSD DMARC is specific= ally tied to the PSL when the text indicating so has been removed (Dave'= ;s email was two months ago and things have changed in the interim).

I don't think the proposed note says anything the status of experimenta= l shouldn't already communicate.=C2=A0 Given the current state of the d= raft, I don't think it's necessary to have such a note.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000005722da05970f2b72-- From nobody Mon Nov 11 07:39:16 2019 Return-Path: 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 558711208AB for ; Mon, 11 Nov 2019 07:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 Y-RQY0Ra8sUq for ; Mon, 11 Nov 2019 07:39:11 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D07E1208A8 for ; Mon, 11 Nov 2019 07:39:11 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id q83so15060556iod.1 for ; Mon, 11 Nov 2019 07:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mh5UEmYeff083gHhmMqOj+m+XPFtXcJBivzNkrxKjR0=; b=JnpatvK2bYjcZ+2fH1+L394jIEm5LKe/Gw9VeJATHuPFe4Sl7Y8Vy/EML1ovUJM6Ge zCYFm/3QrD7sRD2XW6kFhhtrQnhkfFxrAYNM8/Z+DqsrHXGoUCSqletwuc2T4tMAZf5D RZ8B0EvIrCphu4sJvmASSjEbCH6jLdubcZZrE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mh5UEmYeff083gHhmMqOj+m+XPFtXcJBivzNkrxKjR0=; b=sVR+bx7LB2funGRsAYjMeNh9dfr5Sd9DEr3nCVvFNnRY9VqmCRRsyFl959Qene30hU 6I47zm60yhrRBOmr7tr2buMmAPEj9Ajyc0bgNKWD/RHgmWHM2EH0b6NdRwsjPXDveHcM Zv5UofTiWEi0O7y3rHRDFpZugETkz51ETsJWVhg6IF/oLxOB8hWnik4lvCBXXS8x/jqg CRPJkH0hNsvAQOsrcJlGYIvoG+/5fe0O1ALR2O81dLpsNWubNo3TR+EV6eCyId4pg5GM +CRzYxXlypnX2rFWykjjMQjdoMl2QglBlJ/fT4doh9xpCoah7Pjy4gP5l6uWiXzKLKkt Rqow== X-Gm-Message-State: APjAAAWMA6EhlINjo23Apm/ZhqZ19y1mFTY7ZksG0Ts7DTVLKIWQOmXv CSz36x40qD4OtYD+hL8OjyF1FXAdjZRlme+94xdvlQ== X-Google-Smtp-Source: APXvYqwmRT5Y24yp+TJD2DsMQOT7Mdr/nzqB0eg1aaVT7IYaGCYPotnkvBY7cftG1ERPaoHohXNXFEaTBquJiCFgMjE= X-Received: by 2002:a6b:7e0a:: with SMTP id i10mr6376221iom.120.1573486749841; Mon, 11 Nov 2019 07:39:09 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 11 Nov 2019 07:38:50 -0800 Message-ID: To: Tim Wicinski Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c89426059713ee4f" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 15:39:14 -0000 --000000000000c89426059713ee4f Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski wrote: > Scott > > PSD DMARC does talk about organizational domains which from the original > DMARC spec (section 3.2) > does say 'Acquire a "public suffix" list' > > The addition of the preamble text shouldn't move the document in either > direction. > I do feel anything which helps focus us on moving forward on DMARC-bis is > a good thing. > The WG should be able to start writing the PSL document right away. > > Murray and I will be in Singapore if anyone wishes to speak their mind. > > thanks > Tim > > > > > On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman > wrote: > >> >> >> On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" < >> superuser@gmail.com> wrote: >> >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker wrote: >> > >> >> > 1. The change to DMARC should be limited to permitting the query >> >for the >> >> > organization domain to be anywhere in the DNS tree, including a >> >TLD. >> >> > Within DMARC this would not look like 'extra' mechanism. >> >> > >> >> > 2. The mechanism that processes that query should be cast strictly >> >as a >> >> > PSL enhancement, independent of DMARC. >> >> >> >> >> >> Trying to refine things further: >> >> >> >> >> >> DMARC does not care about the PSL. >> >> >> >> What DMARC cares about is the Organizational Domain (OD), as a >> >> fallback when no DMARC record is found at the desired domain name. >> >> >> >> That is, PSL is literally outside the scope of DMARC. >> >> >> >> At the least, therefore, the DMARC specification should define a >> >> distinct interface to the outside functionality that tells DMARC >> >where >> >> the OD is, which will return what suffix of the full domain name is >> >the >> >> OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix >> >> >> >> The PSL-related side of that interface should be a separate >> >> specification, so that changes to its behavior -- such as has been >> >> happening with the introduction of ODs that are TLDs or are otherwise >> >> 'above' where DMARC has been guessing the OD to be -- are isolated >> >from >> >> DMARC. >> >> >> >> The current problems are that DMARC has embedded too much detail >> >> about the PSL world, yet DMARC has no involvement in that world. The >> >> current proposal embeds assumptions of PSL knowledge further, rather >> >> than separating PSL knowledge out. >> >> >> > >> >We (the chairs) fully agree with all of this. What we -- I in >> >particular >> >-- have been struggling with is to find a path forward so the PSD >> >experiment can still take place without being blocked by the need to >> >first >> >go back and overhaul RFC 7489 as you've described here, separating >> >DMARC >> >and the OD determination. Because that'll take months. >> > >> >We are perhaps in the fortuitous position in our charter now that our >> >very >> >next work item is to take up the task of reopening DMARC itself, and >> >the >> >separation of function Dave is espousing could be made into a reality >> >during that work. Given this, we suggest that the PSD draft be allowed >> >to >> >proceed as Experimental, but with appropriate preamble text added to >> >its >> >Introduction explaining the deficiency Dave has identified. So the >> >order >> >of operations becomes: >> > >> >* add text to the PSD draft making it clear that what it's describing >> >is an >> >experiment whose outcome will be taken only as feedback to the revision >> >of >> >the standard (i.e., this is not intended to be the final form of >> >anything), >> >and it is not intended to be deployed outside of the experiment's >> >participants; >> >* publish the experiment with those cautions and allow the experiment >> >to >> >begin >> >* while the experiment is running, spin up the work on two new >> >standards >> >track documents, in line with our charter: >> >a) DMARC, with PSL references replaced by the abstract notion of the OD >> >that's determined in some non-specific way, as Dave suggests >> >b) a PSL document that satisfies the abstract notion of OD in the DMARC >> >document, also as Dave suggests >> >* when the experiment completes, either augment (b) if it's still in >> >development, or publish a revision to it, based on what the experiment >> >has >> >revealed >> > >> >Can this be made to work? >> > >> >Honestly, the experiment could start anyway without an RFC published, >> >but a >> >formal record of the experiment and its caveats doesn't strike me as a >> >wrong thing to do. >> >> The current revision of the PSD DMARC draft makes no reference to the PSL >> in the body of the draft (it only comes up in Appendix A and C). It >> seems like an odd choice to continue to insist PSD DMARC is specifically >> tied to the PSL when the text indicating so has been removed (Dave's email >> was two months ago and things have changed in the interim). >> >> I don't think the proposed note says anything the status of experimental >> shouldn't already communicate. Given the current state of the draft, I >> don't think it's necessary to have such a note. >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000c89426059713ee4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Scott

PSD DMARC does talk about organizational = domains which from the original DMARC spec (section 3.2)=C2=A0
do= es say 'Acquire a "public suffix" list'

The addition of the preamble text shouldn't move the document i= n either direction.=C2=A0
I do feel anything which helps focus us= on moving forward on DMARC-bis is a good thing.=C2=A0
The WG sho= uld be able to start writing the PSL document right away.=C2=A0
<= br>
Murray and I will be in Singapore if anyone wishes to speak t= heir mind.

thanks
Tim




=
On Mon, Nov 11, 2019 at 3:29 AM Scott= Kitterman <sk= list@kitterman.com> wrote:


On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <superuser@gmail.com<= /a>> wrote:
>On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <dcrocker@gmail.com> wrote:
>
>> > 1. The change to DMARC should be limited to permitting the qu= ery
>for the
>> > organization domain to be anywhere in the DNS tree, including= a
>TLD.
>> > Within DMARC this would not look like 'extra' mechani= sm.
>> >
>> > 2. The mechanism that processes that query should be cast str= ictly
>as a
>> > PSL enhancement, independent of DMARC.
>>
>>
>> Trying to refine things further:
>>
>>
>>=C2=A0 =C2=A0 =C2=A0DMARC does not care about the PSL.
>>
>>=C2=A0 =C2=A0 =C2=A0What DMARC cares about is the Organizational Do= main (OD), as a
>> fallback when no DMARC record is found at the desired domain name.=
>>
>>=C2=A0 =C2=A0 =C2=A0That is, PSL is literally outside the scope of = DMARC.
>>
>>=C2=A0 =C2=A0 =C2=A0At the least, therefore, the DMARC specificatio= n should define a
>> distinct interface to the outside functionality that tells DMARC >where
>> the OD is, which will return what suffix of the full domain name i= s
>the
>> OD --=C2=A0 eg, getOrgDomain(full-domain) -> org-domain-suffix<= br> >>
>>=C2=A0 =C2=A0 =C2=A0The PSL-related side of that interface should b= e a separate
>> specification, so that changes to its behavior -- such as has been=
>> happening with the introduction of ODs that are TLDs or are otherw= ise
>> 'above' where DMARC has been guessing the OD to be -- are = isolated
>from
>> DMARC.
>>
>>=C2=A0 =C2=A0 =C2=A0The current problems are that DMARC has embedde= d too much detail
>> about the PSL world, yet DMARC has no involvement in that world. T= he
>> current proposal embeds assumptions of PSL knowledge further, rath= er
>> than separating PSL knowledge out.
>>
>
>We (the chairs) fully agree with all of this.=C2=A0 What we -- I in
>particular
>-- have been struggling with is to find a path forward so the PSD
>experiment can still take place without being blocked by the need to >first
>go back and overhaul RFC 7489 as you've described here, separating<= br> >DMARC
>and the OD determination.=C2=A0 Because that'll take months.
>
>We are perhaps in the fortuitous position in our charter now that our >very
>next work item is to take up the task of reopening DMARC itself, and >the
>separation of function Dave is espousing could be made into a reality >during that work.=C2=A0 Given this, we suggest that the PSD draft be al= lowed
>to
>proceed as Experimental, but with appropriate preamble text added to >its
>Introduction explaining the deficiency Dave has identified.=C2=A0 So th= e
>order
>of operations becomes:
>
>* add text to the PSD draft making it clear that what it's describi= ng
>is an
>experiment whose outcome will be taken only as feedback to the revision=
>of
>the standard (i.e., this is not intended to be the final form of
>anything),
>and it is not intended to be deployed outside of the experiment's >participants;
>* publish the experiment with those cautions and allow the experiment >to
>begin
>* while the experiment is running, spin up the work on two new
>standards
>track documents, in line with our charter:
>a) DMARC, with PSL references replaced by the abstract notion of the OD=
>that's determined in some non-specific way, as Dave suggests
>b) a PSL document that satisfies the abstract notion of OD in the DMARC=
>document, also as Dave suggests
>* when the experiment completes, either augment (b) if it's still i= n
>development, or publish a revision to it, based on what the experiment<= br> >has
>revealed
>
>Can this be made to work?
>
>Honestly, the experiment could start anyway without an RFC published, >but a
>formal record of the experiment and its caveats doesn't strike me a= s a
>wrong thing to do.

The current revision of the PSD DMARC draft makes no reference to the PSL i= n the body of the draft (it only comes up in Appendix A and C).=C2=A0 =C2= =A0 It seems like an odd choice to continue to insist PSD DMARC is specific= ally tied to the PSL when the text indicating so has been removed (Dave'= ;s email was two months ago and things have changed in the interim).

I don't think the proposed note says anything the status of experimenta= l shouldn't already communicate.=C2=A0 Given the current state of the d= raft, I don't think it's necessary to have such a note.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000c89426059713ee4f-- From nobody Mon Nov 11 07:46:40 2019 Return-Path: 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 3164912089E for ; Mon, 11 Nov 2019 07:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 4xiXz1bywae4 for ; Mon, 11 Nov 2019 07:46:37 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223EA1200B2 for ; Mon, 11 Nov 2019 07:46:37 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id k1so15080369ioj.6 for ; Mon, 11 Nov 2019 07:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ije/aDwslIHUNif2pyijYGIhGMMTpFSyPDXKI1NMJ0=; b=IxSR78XPDpin1/gq65RRFICStdbZJSvi7Cbd+WR33d3mkHc8XtuHXPmFa9X63OfULm 14/raB5yUwdrhtJ360RyPJnTw6PnG4oHCzVg2manlXRS4QaQ9dKEqU6bgnkYXUCBnWqC YtCpHOlUDWBRlpyyMyAeYNxUd52EGt617Xd+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ije/aDwslIHUNif2pyijYGIhGMMTpFSyPDXKI1NMJ0=; b=JRKleAJW6wBhteQ5Aj0+AgQl2KRutHpcxJjTvAgRXAR2K/Ht6ifPNU7nheuJsoyxR5 +DNdsplqbyGrNCnpFe4evUxFSSdqdWp6T0C7levc6SDEPxdGITRe0rnhlRXYa78Nevbk MrMx84TCOACE6OPOUhXBPoe2O5vHupYYhHAqwkU1eqECSUHTqPF2Ub69raG+jC7mMizF LKibc1gJabBlfOONKNaASaSN+qAlRlp59zMVgASBWevJ6wmkYAkzSumZpi/846hSJQcx tYfujcm6vjWX9Yu4GnuFWGJdJtBFF6gt56qV5owA/Or+XAQf4en1aoSf6aTOnCdBc8Qp hULQ== X-Gm-Message-State: APjAAAVSchnVNo41dR2T269Z85RJB6WgzCIKxQAFkp5H8KH4bOsn/cxA TioOapudgtrtbSHvtWwiEgq59NTEU4XS9i2uoSMMxQ== X-Google-Smtp-Source: APXvYqxlXz0Umoj8/w6QhAjQyC87ou5XmjHNwbJAL1o1ZapzjorpKviavszj6iOk9fh6xiTvGNgVhdHgEixgh92L+yQ= X-Received: by 2002:a5d:8051:: with SMTP id b17mr6381126ior.104.1573487196105; Mon, 11 Nov 2019 07:46:36 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 11 Nov 2019 07:46:17 -0800 Message-ID: To: Tim Wicinski Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000623b790597140953" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 15:46:39 -0000 --000000000000623b790597140953 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski wrote: > Scott > > PSD DMARC does talk about organizational domains which from the original > DMARC spec (section 3.2) > does say 'Acquire a "public suffix" list' > > The addition of the preamble text shouldn't move the document in either > direction. > I do feel anything which helps focus us on moving forward on DMARC-bis is > a good thing. > The WG should be able to start writing the PSL document right away. > Tim, I think that you are being too liberal in applying transitive references. The PSD document only refers to the PSL in - Informative References - Appendix A.1 - Appendix B.3 - Appendix C.2 (implementations) I don't think that it is fair to say that anyone who refers to the org domain concept as cited in the DMARC spec is necessarily invoking the PSL. I do have a problem with the conflation of the org domain with a super-organizational "realm" (?) that may impose conditions upon organizations that fall within their jurisdictional purview. My main concerns are with the potential usurpation of the org domain's policy declaration rights. "Moving" the org domain up one level disenfranchises the organizations and that is the wrong thing to do IMO. As to the proposed "let's run this as an experiment pending DMARCbis", I don't see how that satisfies Dave's concern about creating new work for receivers in order to help a small set of domain (realm) owners. I'm not opposed to it, but I just don't see how this solves the issue. --Kurt --000000000000623b790597140953 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 11, 2019 at 1:58 AM Tim Wicin= ski <tjw.ietf@gmail.com> wr= ote:
Scott

= PSD DMARC does talk about organizational domains which from the original DM= ARC spec (section 3.2)=C2=A0
does say 'Acquire a "public= suffix" list'

The addition of the preamb= le text shouldn't move the document in either direction.=C2=A0
I do feel anything which helps focus us on moving forward on DMARC-bis is= a good thing.=C2=A0
The WG should be able to start writing the P= SL document right away.=C2=A0

=
Tim,

I think that you are being too liberal i= n applying transitive references. The PSD document only refers to the PSL i= n=C2=A0
  • Informative References
  • Appendix A.1
    • <= li>Appendix B.3
  • Appendix C.2 (implementations)
I don't= think that it is fair to say that anyone who refers to the org domain conc= ept as cited in the DMARC spec is necessarily invoking the PSL.
<= br>
I do have a problem with the conflation of the org domain wit= h a super-organizational "realm" (?) that may impose conditions u= pon organizations that fall within their jurisdictional purview. My main co= ncerns are with the potential usurpation of the org domain's=C2=A0polic= y declaration rights. "Moving" the org domain up one level disenf= ranchises the organizations and that is the wrong thing to do IMO.

As to the proposed "let's run this as an experime= nt pending DMARCbis", I don't see how that satisfies Dave's co= ncern about creating new work for receivers in order to help a small set of= domain (realm) owners. I'm not opposed to it, but I just don't see= how this solves the issue.

--Kurt=C2=A0
=
--000000000000623b790597140953-- From nobody Mon Nov 11 07:50:55 2019 Return-Path: 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 2BB181200B2 for ; Mon, 11 Nov 2019 07:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 SPTMWx636UYX for ; Mon, 11 Nov 2019 07:50:50 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5574012008B for ; Mon, 11 Nov 2019 07:50:50 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id p6so12502098ilp.1 for ; Mon, 11 Nov 2019 07:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YwZTuDPSHuFBPBeFQAdap2/nJUxLrNj54lLAYVaLfqw=; b=V+M7dRWSF3vkpQmA2d8RluPB6XDTLFSJvqUcwVAOEA/HBQUZSLYzDR/vJYOK8UbYuh /ZwGw7mK7TKHT/RfHH6Sh6ftGxYlRpkPoMGN5nMA9u8tX/Myt0skRS0CoqVEUNwApJXE lvIPrupewggNtoqti2YJwQD1YjMaqFGGWJVAk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YwZTuDPSHuFBPBeFQAdap2/nJUxLrNj54lLAYVaLfqw=; b=r39K5UaFhvhC4XC9ZNG3ajU7DjxGXAsq/HkmrBNxG2z8MD8G+cKNNsmi74umGHu5OO v0QcC5K57UJrcdzpA2t/WRoZTNta95TiEWdGWi683a6SoJ1dTx88HThvhlnpmJviQw11 VsSH3iXwFzSo9s6D48MwYEvwC/IL8DM/OlZHupv/b/Fdn3MGY97H/X0e61LXETCWJZfr iK634OtG6+yW4MEzkGzZvxZOtbul2pmY6s7U9DPBHe7AMTcBlikvIMur4xr/xyl6E3MC ml2tWr0YrP8sdHcPO8VOsrcbDs9P9vSY9Sf9Ly/bcepwRIHZnyOgwgHxYTPVhemknJTs DhVQ== X-Gm-Message-State: APjAAAUDF/aa5/1dDFEGoly/CDwcxj75C5HtPTrijt8s72IIvQQsdVID 78K7sihS5rpnb+9KtVt6BCSo/L3mZUezRqjRgnU5Pw== X-Google-Smtp-Source: APXvYqwc62JJn9r5dv4i4IA9Pymf2lfTqASzaPlixCmiw/1DG0Ont8gFOY5XqzbLzZDNP2yDyfigClVPOQvT0AkhE4A= X-Received: by 2002:a92:831d:: with SMTP id f29mr31266415ild.263.1573487449328; Mon, 11 Nov 2019 07:50:49 -0800 (PST) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 11 Nov 2019 07:50:30 -0800 Message-ID: To: Alessandro Vesely Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000079ed7d0597141854" Archived-At: Subject: Re: [dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype? X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 15:50:52 -0000 --00000000000079ed7d0597141854 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 1:23 AM Alessandro Vesely wrote: > > Does the WG agree to an erratum as follows: > > TYPE: technical > > SECTION: 2.3 > > ORIGINAL TEXT: > > smtp: Indicates information that was extracted from an SMTP command > that was used to relay the message. The "property" indicates > which SMTP command included the extracted content as a parameter. > > CORRECTED TEXT: > > smtp: Indicates information that was extracted from a parameter of > the SMTP session that was used to relay the message. The > "property" indicates which parameter included the extracted content. > > NOTES > > This change makes the "smtp" type consistent with the definition of > smtp.remote-ip given in rfc8617 Section 10.2. > This seems like a bit of a nit, but also seems to be an accurate wordsmithing of the definition. --Kurt --00000000000079ed7d0597141854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 11, 2019 at 1:23 AM Alessandr= o Vesely <vesely@tana.it> wrote= :

Does the WG agree to an erratum as follows:

TYPE: technical

SECTION: 2.3

ORIGINAL TEXT:

=C2=A0 =C2=A0smtp:=C2=A0 Indicates information that was extracted from an S= MTP command
=C2=A0 =C2=A0 =C2=A0 that was used to relay the message.=C2=A0 The "pr= operty" indicates
=C2=A0 =C2=A0 =C2=A0 which SMTP command included the extracted content as a= parameter.

CORRECTED TEXT:

=C2=A0 =C2=A0smtp:=C2=A0 Indicates information that was extracted from a pa= rameter of
=C2=A0 =C2=A0 =C2=A0 the SMTP session that was used to relay the message.= =C2=A0 The
=C2=A0 =C2=A0 =C2=A0 "property" indicates which parameter include= d the extracted content.

NOTES

=C2=A0 =C2=A0This change makes the "smtp" type consistent with th= e definition of
=C2=A0 =C2=A0smtp.remote-ip given in rfc8617 Section 10.2.
=

This seems like a bit of a nit, but also seems to be an= accurate wordsmithing of the definition.

--Kurt= =C2=A0
--00000000000079ed7d0597141854-- From nobody Mon Nov 11 07:54:15 2019 Return-Path: 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 AF49812023E for ; Mon, 11 Nov 2019 07:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=3B2tgk16; dkim=pass (1536-bit key) header.d=taugh.com header.b=YS14128Q 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 pZV4IpGzLpSX for ; Mon, 11 Nov 2019 07:54:12 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 454D112008B for ; Mon, 11 Nov 2019 07:54:12 -0800 (PST) Received: (qmail 57559 invoked from network); 11 Nov 2019 15:54:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e0d5.5dc98422.k1911; i=printer-iecc.com@submit.iecc.com; bh=RPZq+FSASmAtGV9LgQpLX0MGdA5LcdWqbDXK2R/8ukc=; b=3B2tgk16yd6JDWEGvYFgtMF5ubvAR4O6GFSWZcrY9GiSx9yHXtVi7wLgJR68SZldCtKktfj5cmQ+Pttw0DwrN5eK5QMYKeAbEx95mj47wnNq3jyZ3hWq+7oVblS56tiOLSDl2CM6NSHtWGek9zgoPJ+0BBZVBhNRpSe+btY0nMNy+UmEfYkCam+e/dEUBSkMo4DgH3uZJ5h3Rm1vgdFgizGw/F5QxwB2SYtB1UCZdoszwxrt+buiDmmp3XHYQlYf DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e0d5.5dc98422.k1911; olt=printer-iecc.com@submit.iecc.com; bh=RPZq+FSASmAtGV9LgQpLX0MGdA5LcdWqbDXK2R/8ukc=; b=YS14128Q6R7JOjSRrnKUy3XgfyRTJ+b6U2WkgWBqNLeYfH3lTCyNC6zJeatWFdnr/KnpfEJxbNJMCNTvXfQ+pBQJQFsAgpWxpumty6QB8rMFT0UXW7vMwPZyMwsRl8huwrbmGfOVx1tAjDFsuQK3NNba/7KbB5EOJQWGWsS6wfr6wCDflfsPT9YxtP6uceigw1EZkF5x6K65colbtYSm+AJRPAjx9YsK+mXngt8lC+xSzb3evx0IQBJ77Kk2Vo9f Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 11 Nov 2019 15:54:10 -0000 Received: by ary.qy (Postfix, from userid 501) id 12A31E9E35A; Mon, 11 Nov 2019 10:54:09 -0500 (EST) Date: 11 Nov 2019 10:54:09 -0500 Message-Id: <20191111155410.12A31E9E35A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 15:54:14 -0000 In article you write: >Just to be clear: The policy for changes to that registry is "Expert >Review", but since the action that put it there was a document with IETF >consensus, I'm pretty hesitant about just approving this change based on a >formal request. I'd rather at least see some consensus discussion about >it, or even better, a revision/update to RFC8601. Hey, wait, Expert Review is supposed to be considerably looser than RFC Required. Since there's no danger of running out of token names, I'd encourage you to accept new ptypes if they have a clear spec and a plausible use case. In this instance, I think the description in the I-D is OK, but for the use case I would like some evidence that someone, somewhere is implementing it and doing something with the result. R's, John From nobody Mon Nov 11 09:50:36 2019 Return-Path: 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 74CF7120AF8 for ; Mon, 11 Nov 2019 09:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 iq-diobT7qCj for ; Mon, 11 Nov 2019 09:50:32 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E51120A59 for ; Mon, 11 Nov 2019 09:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573494630; bh=I8TUJEwp/tODVq0r0WhwgHx/3c4XnIjrBZXoyc7SYMY=; l=1572; h=To:References:From:Date:In-Reply-To; b=BrcimReCZoGez+RbsYLjMDGfI6hHuwi6DYOHEMv3BWNfNrocDlGhzZxJFG495VS/b 2URPRec35Z97lPfwG5T8bGhKvCViMaIDEJgGy/nWMzQhGK29a3yobVD42syWAKDQgz AS7kD0aVk3ZLv64UJFLs4tcj5pXE88sZRLEfKLGGE1oy+M1Lg1jWstC+7O4vN Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC053.000000005DC99F66.0000461E; Mon, 11 Nov 2019 18:50:30 +0100 To: dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> Date: Mon, 11 Nov 2019 18:50:30 +0100 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] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 17:50:35 -0000 On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote: > > I don't think that it is fair to say that anyone who refers to the org domain > concept as cited in the DMARC spec is necessarily invoking the PSL. Agreed. The PSL just happens to be the only valid tool to do that. For various reasons, large organizations administer many apparently unrelated domains. For example, _dmarc.youtube.com has a rua mailto ending in @google.com. We cannot infer an OD from that, but I think the concept is clear. > I do have a problem with the conflation of the org domain with a > super-organizational "realm" (?) that may impose conditions upon organizations > that fall within their jurisdictional purview. My main concerns are with the > potential usurpation of the org domain's policy declaration rights. "Moving" > the org domain up one level disenfranchises the organizations and that is the > wrong thing to do IMO. The I-D definitions are clear enough. Section 2.5, in particular, prevents the conflation neatly. > As to the proposed "let's run this as an experiment pending DMARCbis", I don't > see how that satisfies Dave's concern about creating new work for receivers in > order to help a small set of domain (realm) owners. I'm not opposed to it, but > I just don't see how this solves the issue. Isn't that an ICANN problem? For the time being, dig _dmarc.bank txt returns an empty NOERROR response, while _dmarc.gov.uk returns a valid record. The latter is a Nominet, already solved problem, AFAICS. Best Ale -- From nobody Mon Nov 11 10:32:17 2019 Return-Path: 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 E7063120BE3 for ; Mon, 11 Nov 2019 10:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 L4j0XOO1jzuQ for ; Mon, 11 Nov 2019 10:32:12 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC39120BE7 for ; Mon, 11 Nov 2019 10:32:12 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id i13so14333658ioj.5 for ; Mon, 11 Nov 2019 10:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K03ioOeyfCbwgfZY+U+EjgM7ENyGoGSI6tiFee9ZttQ=; b=I6k/PjYuRwYwsCNs5rVDCUjXaq1CmOIhXaLTSpf+UvwnyyPhQAKBGqzMoPDZEG2lW3 Ni6MgRfu050s8niPwCwcgLVXjS0kxm6Cv12pkfabROLTEPtTd2MyKpnBIcPiLYUz9Pob jVkJ4ZFTOvbmqGR//4ii2AY4F4GJTA22jxSxA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K03ioOeyfCbwgfZY+U+EjgM7ENyGoGSI6tiFee9ZttQ=; b=sJcUP8eMxbdlnac5WB/+pL53EOhXnAD4NR6zBj0jVEdBKQhIgG/DwN2i7o5iYf5AHt UW972pkop0MUvK5UBQXF10vD6wQ8KPb7LEqUF+i4XkS7Sc7WuXsvbHuaufUtF3lkYkoh 87a3/nVBEJrjZUaZdA9Vo0PPPleOgxkHEG+xWNUIVk+V2CxiBUrdo/7ujvz3SEZTqLgg P6odS34S7sLGrH/gtWapz0+n4gDo7MI5oB4ljZ1nRkTSfaF6Q8TFs0DbPL1BchvR/KEb sRNTQVsrFHp1VdgtpYk/QJ1Fv0auH0eZfms+39+jCRb7hK32MzWqseAMYVwe0FereQHC 9xAA== X-Gm-Message-State: APjAAAW34iSguddiR6g99Go2unKenIpIxXbM6knqzod2GgpmPXPJr03Q 4s+n71gePhase9LdRv6xgEllvKHdRpnU3b2Ql+eBcEJbhs0= X-Google-Smtp-Source: APXvYqwNF3VQhIhsT9N4O+ePTgTMH8EMRgUXz5W5nCg9P0bxPI/vGAUkvSS8wT7JWfaT9AV3n0iieQIxnWfwWmfB+Mk= X-Received: by 2002:a05:6638:73a:: with SMTP id j26mr26751143jad.116.1573497131462; Mon, 11 Nov 2019 10:32:11 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> In-Reply-To: <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> From: "Kurt Andersen (b)" Date: Mon, 11 Nov 2019 10:31:52 -0800 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000939973059716598e" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 18:32:16 -0000 --000000000000939973059716598e Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely wrote: > On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote: > > > > I don't think that it is fair to say that anyone who refers to the org > domain > > concept as cited in the DMARC spec is necessarily invoking the PSL. > > Agreed. The PSL just happens to be the only valid tool to do that. > Which was not what I thought Tim W was talking about... > For various reasons, large organizations administer many apparently > unrelated > domains. For example, _dmarc.youtube.com has a rua mailto ending in > @google.com. We cannot infer an OD from that, but I think the concept is > clear. > I don't think this has anything to do with the PSD proposal either. Why do you bring it up? > > As to the proposed "let's run this as an experiment pending DMARCbis", I > don't > > see how that satisfies Dave's concern about creating new work for > receivers in > > order to help a small set of domain (realm) owners. I'm not opposed to > it, but > > I just don't see how this solves the issue. > > Isn't that an ICANN problem? For the time being, dig _dmarc.bank txt > returns > an empty NOERROR response, while _dmarc.gov.uk returns a valid record. > The > latter is a Nominet, already solved problem, AFAICS. > If it was a solved problem, then we would not need a PSD (or realm) I-D and this whole discussion would be moot. What ICANN does and does not allow is out of scope for the IETF/protocol work (though I do acknowledge that ICANN may consider protocol factors when making decisions - or I would hope that they would). --Kurt --000000000000939973059716598e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 11, 2019 at 9:50 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
>
> I don't think that it is fair to say that anyone who refers to the= org domain
> concept as cited in the DMARC spec is necessarily invoking the PSL.
Agreed.=C2=A0 The PSL just happens to be the only valid tool to do that.

Which was not what I thought Tim W was ta= lking about...
=C2=A0
For various reasons, large organizations administer many appare= ntly unrelated
domains.=C2=A0 For example, _dmarc.youtube.com has a rua mailto ending i= n
@google.= com.=C2=A0 We cannot infer an OD from that, but I think the concept is = clear.

I don't think this has anyth= ing to do with the PSD proposal either. Why do you bring it up?
= =C2=A0
> As to th= e proposed "let's run this as an experiment pending DMARCbis"= , I don't
> see how that satisfies Dave's concern about creating new work for = receivers in
> order to help a small set of domain (realm) owners. I'm not oppose= d to it, but
> I just don't see how this solves the issue.

Isn't that an ICANN problem?=C2=A0 For the time being, dig _dmarc.bank = txt returns
an empty NOERROR response, while _dmarc.gov.uk returns a valid record.=C2=A0 = The
latter is a Nominet, already solved problem, AFAICS.
<= br>
If it was a solved problem, then we would not need a PSD (or = realm) I-D and this whole discussion would be moot. What ICANN does and doe= s not allow is out of scope for the IETF/protocol work (though I do acknowl= edge that ICANN may consider protocol factors when making decisions - or I = would hope that they would).

--Kurt
--000000000000939973059716598e-- From nobody Mon Nov 11 12:08:11 2019 Return-Path: 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 C04D012081C for ; Mon, 11 Nov 2019 12:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=rafvkf28; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Z3juQZ7f 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 YLnhn01RlpvY for ; Mon, 11 Nov 2019 12:08:08 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D44B12022E for ; Mon, 11 Nov 2019 12:08:02 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id D1D8EF804AA; Mon, 11 Nov 2019 15:07:58 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1573502878; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=wpV//jWgDgmMyRc2gGz+lkQ67TfevmJG33rIyGbNaZ4=; b=rafvkf28Ih6IcifYDfyPRAJ6AwT0wmSBCm6h9erhtcvKgxxhMiudMnSu tQNg1GF82qP4JGkq8Xqvi8NDPcb9BA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1573502878; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=wpV//jWgDgmMyRc2gGz+lkQ67TfevmJG33rIyGbNaZ4=; b=Z3juQZ7f0vAloOSoV5yPlEIzIbCSGoF4l6uXZMnGmSC1tDIWC0t3VZ2U nQUpleT0fUJl1cdcawAPQWYAuwKpUx7n7984JMfOJDETsd+6jJJRYb47kZ PD8WbN/uiKdQHpqz1zLeENMQAb6ITXNdsgai60g8OLBaUAp4OoJE1tnglf 4m58Uq79tX0Apcr+Lh+ZxT5/qyzqi5Ho6e79YHSptS0ROpr1UmHGj5/IwZ OVDXdAM3NjpVtvXp7vhEwl0JnxuZNk/K2RLqdY/y8thp1Q+/Uz48d7PQr6 8GgUBszw0XOCDXOuRbePa5G7e7803tiJOCDkfiUBa+UpavAZAeP7DA== Received: from [10.8.227.33] (mobile-166-170-34-138.mycingular.net [166.170.34.138]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8A8D7F80041; Mon, 11 Nov 2019 15:07:58 -0500 (EST) Date: Mon, 11 Nov 2019 20:07:50 +0000 In-Reply-To: <20191111155410.12A31E9E35A@ary.qy> References: <20191111155410.12A31E9E35A@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <6A590DA7-4EE9-4C68-9932-89F6110AE158@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 20:08:10 -0000 On November 11, 2019 3:54:09 PM UTC, John Levine wrote= : >In article > >you write: >>Just to be clear: The policy for changes to that registry is "Expert >>Review", but since the action that put it there was a document with >IETF >>consensus, I'm pretty hesitant about just approving this change based >on a >>formal request=2E I'd rather at least see some consensus discussion >about >>it, or even better, a revision/update to RFC8601=2E > >Hey, wait, Expert Review is supposed to be considerably looser than RFC >Required=2E > >Since there's no danger of running out of token names, I'd encourage >you to accept new ptypes if they have a clear spec and a plausible use >case=2E In this instance, I think the description in the I-D is OK, but >for the use case I would like some evidence that someone, somewhere is >implementing it and doing something with the result=2E I've had feature requests to include both s=3D Service Type (due to tlsrpt= ) and t=3D Flags (particularly t=3Dy (testing))=2E Since they are attribut= es of the DNS record and not the signature, I think the proposed dns ptype = would be appropriate=2E I plan to implement it in dkimpy and expose the values in dkimpy-milter=2E= I'd like some indication that it'll move forward first=2E I think we can adequately define the ptype in the registry=2E I don't thi= nk we need to have a spec=2E For the rest of Ale's draft, I'm not convince= d a registry entry is enough to document the proposed usage=2E (Speaking as= alternate DE - msk is the primary though, so this is not an attempt to ove= rride him)=2E msk: What do you think about the idea of approving the new ptype now (so I= can file requests for the above, well defined, DKIM result reporting enhan= cements)? Scott K From nobody Mon Nov 11 12:43:17 2019 Return-Path: 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 CB7F2120825 for ; Mon, 11 Nov 2019 12:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 Gr8z1UAx8dii for ; Mon, 11 Nov 2019 12:43:15 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2884D12004E for ; Mon, 11 Nov 2019 12:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573504990; bh=vBTdQxyX2IEvwUqSJZG5FngPRpJHXObqnoXF9IfXG4Y=; l=1886; h=To:Cc:References:From:Date:In-Reply-To; b=AdzmG9cIZ3rkqouqDNAki3ROh7y7COyJjHIzgh50gR1NsyJDb3GxUmmxq/rNo/OHQ YoeUrNcGXotXWCHkHKa5ds0OoFIlhXDXjy+QzHzKjmQh4caxL317xERv1bgNtXaf9w mb2tH+K522J+DiCwDzlNC32MQKn+gJ2KXOEPmPGA7JlvO8A9nSlA6utrItEP5 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC073.000000005DC9C7DE.00005D3B; Mon, 11 Nov 2019 21:43:10 +0100 To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Mon, 11 Nov 2019 21:43:10 +0100 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=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 20:43:17 -0000 On Mon 11/Nov/2019 19:31:52 +0100 Kurt Andersen (b) wrote: > On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely wrote: > >> For various reasons, large organizations administer many apparently >> unrelated domains. For example, _dmarc.youtube.com has a rua mailto >> ending in @google.com. We cannot infer an OD from that, but I think the >> concept is clear.>> > > I don't think this has anything to do with the PSD proposal either. Why do > you bring it up? If it were possible to infer OD from some kind of DNS record (or from RDAP responses, for another way) then we'd have a tool alternative to the PSL. That proves that the concept of OD is independent of the PSL, doesn'it? >>> As to the proposed "let's run this as an experiment pending DMARCbis", >>> I don't see how that satisfies Dave's concern about creating new work >>> for receivers in order to help a small set of domain (realm) owners. I'm >>> not opposed to it, but I just don't see how this solves the issue.>> >> Isn't that an ICANN problem? For the time being, dig _dmarc.bank txt >> returns an empty NOERROR response, while _dmarc.gov.uk returns a valid >> record. The latter is a Nominet, already solved problem, AFAICS.>> > > If it was a solved problem, then we would not need a PSD (or realm) I-D and > this whole discussion would be moot. What ICANN does and does not allow is > out of scope for the IETF/protocol work (though I do acknowledge that ICANN > may consider protocol factors when making decisions - or I would hope that > they would). Oh, you meant the receivers burden of an extra lookup? Sorry, I though it was about the need for each OD to opt out by defining its own DMARC record, lest have reports delivered to the realm. In the latter sense, Nominet solved the problem of what rights has gov.uk on domains below it. Best Ale -- From nobody Mon Nov 11 13:27:43 2019 Return-Path: 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 E5AE412083A for ; Mon, 11 Nov 2019 13:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 K3bRMc2wq_Ih for ; Mon, 11 Nov 2019 13:27:41 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B42B12006D for ; Mon, 11 Nov 2019 13:27:41 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id u13so12508381ote.0 for ; Mon, 11 Nov 2019 13:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=azCChxMsa5uRtX7Xfq8/ggxKr4d53wssqZPXKZ03eH8=; b=uVKMsdqcG5fFUMGIi6I2tzgC4fBwdRqfLJTW82RgYKqR6CNhxCyHJt5HFWFervV16g Ub9z88TS6WQaH22hiyWDP29SXEojtJveAwH+4xb5+m/LTCvi+Hiyt//d3WkI4v1y6eKA 7PJ15GahD+vhToXN0R+scNz4NWtngAsp73uV1YdtbGFdPTK9ZQk9nlBISev7uHKSevFV j4fvhPmQ6nvilXKBpdQeoEK5IwnKae3pzZn0UKTaMHCwT48qJWblbjGkBNaykVZb+Xfz TWKvz4fTeLCE0x/3RsbWZfjZhXl0A9hsbSFRrSWgaszhArqbgvhiVC+FwqCOLnYY0zqg JIAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=azCChxMsa5uRtX7Xfq8/ggxKr4d53wssqZPXKZ03eH8=; b=XIzuGYlFFU1Teydz5AW2Fy/bw4ScZsI4NxPf4IgptHctBWsWrxcXP9xfbGwyxWlxcL ArKvOBiHS9WIDBrpdIP3escwvTboOKruzzpstnivlFiAIoVOO6WcLYBcgL9DXtsH3Gcp C7ZAuFQDu0K3JP4r9hhsUKB4JqDj5nF8JP9DhWKb95utmIpsfxg6V81ih4tyPzTrpT7z ZVlfiFNtzjauegJonsYUyLzkywJpQVWLfTFAcDsja+YptFhJRLmxDe2WZAQB6bBW4Rjy hiPQ9alzHpBFgVlNk6Zt1KIEC475bptTm1ixB3goeQh+YqIcLuJL/93g+lHaiuI8g4e4 zeZA== X-Gm-Message-State: APjAAAWwUpvHUddy3etRtyLdOy5AS3ShAnyVR4D1agigQyq1JPgp8lU+ YGhbLbel7lXiQQi3W1ZKQLuBmhnmGcBRefAwf2A55A== X-Google-Smtp-Source: APXvYqx1C2Jvj9KjhqTCQA3l+jNjVnzKPEP1dEtTuAU5DE37HQm42ytE48zSgRckZA1YBEZ1u4gzBYOdYYFMphOLXK4= X-Received: by 2002:a9d:bb6:: with SMTP id 51mr23852100oth.158.1573507660720; Mon, 11 Nov 2019 13:27:40 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> In-Reply-To: From: Tim Wicinski Date: Mon, 11 Nov 2019 16:27:29 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002b2f52059718cdba" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 21:27:43 -0000 --0000000000002b2f52059718cdba Content-Type: text/plain; charset="UTF-8" Kurt You are absolutely correct. We were having such discussions about the PSL origins that I was going back over the DMARC spec and refreshing my memory on how the PSL was defined and used. I wasn't even looking at the PSD document. Tim On Mon, Nov 11, 2019 at 10:46 AM Kurt Andersen (b) wrote: > On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski wrote: > >> Scott >> >> PSD DMARC does talk about organizational domains which from the original >> DMARC spec (section 3.2) >> does say 'Acquire a "public suffix" list' >> >> The addition of the preamble text shouldn't move the document in either >> direction. >> I do feel anything which helps focus us on moving forward on DMARC-bis is >> a good thing. >> The WG should be able to start writing the PSL document right away. >> > > Tim, > > I think that you are being too liberal in applying transitive references. > The PSD document only refers to the PSL in > > - Informative References > - Appendix A.1 > - Appendix B.3 > - Appendix C.2 (implementations) > > I don't think that it is fair to say that anyone who refers to the org > domain concept as cited in the DMARC spec is necessarily invoking the PSL. > > I do have a problem with the conflation of the org domain with a > super-organizational "realm" (?) that may impose conditions upon > organizations that fall within their jurisdictional purview. My main > concerns are with the potential usurpation of the org domain's policy > declaration rights. "Moving" the org domain up one level disenfranchises > the organizations and that is the wrong thing to do IMO. > > As to the proposed "let's run this as an experiment pending DMARCbis", I > don't see how that satisfies Dave's concern about creating new work for > receivers in order to help a small set of domain (realm) owners. I'm not > opposed to it, but I just don't see how this solves the issue. > > --Kurt > --0000000000002b2f52059718cdba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kurt

You are absolutely correct.=C2=A0 = We were having such discussions about the PSL origins=C2=A0that I was going= back over the DMARC spec and refreshing my
memory on how the PSL= was defined and used. I wasn't even looking at the PSD document. =C2= =A0=C2=A0

Tim

On Mon, Nov 11, 2019 at 10:46 A= M Kurt Andersen (b) <kboth@drkurt.co= m> wrote:
On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:
=
Scott

PSD DMARC does talk about organizational domain= s which from the original DMARC spec (section 3.2)=C2=A0
does say= 'Acquire a "public suffix" list'

The addition of the preamble text shouldn't move the document in eith= er direction.=C2=A0
I do feel anything which helps focus us on mo= ving forward on DMARC-bis is a good thing.=C2=A0
The WG should be= able to start writing the PSL document right away.=C2=A0
=

Tim,

I think that= you are being too liberal in applying transitive references. The PSD docum= ent only refers to the PSL in=C2=A0
  • Informative Reference= s
  • Appendix A.1
  • Appendix B.3
  • Appendix C.2 (implement= ations)
I don't think that it is fair to say that anyone who r= efers to the org domain concept as cited in the DMARC spec is necessarily i= nvoking the PSL.

I do have a problem with the conf= lation of the org domain with a super-organizational "realm" (?) = that may impose conditions upon organizations that fall within their jurisd= ictional purview. My main concerns are with the potential usurpation of the= org domain's=C2=A0policy declaration rights. "Moving" the or= g domain up one level disenfranchises the organizations and that is the wro= ng thing to do IMO.

As to the proposed "let&#= 39;s run this as an experiment pending DMARCbis", I don't see how = that satisfies Dave's concern about creating new work for receivers in = order to help a small set of domain (realm) owners. I'm not opposed to = it, but I just don't see how this solves the issue.

--Kurt=C2=A0
--0000000000002b2f52059718cdba-- From nobody Mon Nov 11 13:35:27 2019 Return-Path: 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 AED10120130 for ; Mon, 11 Nov 2019 13:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BCyWsvHK6-1c for ; Mon, 11 Nov 2019 13:35:23 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF698120018 for ; Mon, 11 Nov 2019 13:35:23 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id d5so12529346otp.4 for ; Mon, 11 Nov 2019 13:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=erVFAF+lC2a1rvRE4+fBxHt93bU5wYw5zz1jtJ1LwAA=; b=j2JLhiB4Z6ZHK3ew/k7YIgiq8wCYfb0sJ5UzYcB8s3tVuVo5LzjRBb3R7P9eFdPq3v r4/MzxRScgKc4UN/8KPeFvAezdtLHeTUa3Ss/HRMPVftwVMTXfzBAwowEyeoqyU897pK +dAUmXCrltWRV7P2MSwGrEqmO0NtlLKtfNFV9DsZ23ZTH8V1tfnd3pueiF3SeMp6wn4f vGZCNDVEM9cDeXLzDqEimOd/p13F2AakDkJ/eSMdZFrrK4QFDUozQ/yAclamJZGdPOND Zm/WrtRxL89sf4D9+5zPzNIg9SShzHTea/0utT80k3QKkZUC3QLcqWE3MnClTZ1Uj0ZX iiQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=erVFAF+lC2a1rvRE4+fBxHt93bU5wYw5zz1jtJ1LwAA=; b=PH1qW/3hlLBYEUb3oPGaoZQyHaBUUDgNBmYndLKYjgErcP9aIEsyhTJMvomBo0vQBw O3JXgNMmVUjfIV83FCQaiPY9eU7vY/aFRfkmhohLowx1AcxssHN0CmukXZ/R5ftYKawd UmYEKAbo2MucENLSIvIH9/GD0bhoblgaHFmIHVoxLdos/EecYKP9hYDGI8JP8v4G2tWS yRJU4wjFccnUuRY5yWJn04YpnO84E0rC58ytYKxhEQ61qPKl/aVQOK9T+Rm8+8qTnwA8 gKm579tIFScvMZX/geWikCip12X3iAJjITeFVO0IjUyTlCa480FthPsc8VBH/FHrs/Rq wzLQ== X-Gm-Message-State: APjAAAWX7Q5oFUZUSlIG+2j3jHXteAiId20+yfGjshli1jJ4XFEJshY3 MZAMVxnS46uqFc49lpikWwgiZBFZn8s58HWV9Z0= X-Google-Smtp-Source: APXvYqy8UF6hGmIoqMCoLlCf7ZX8Rw5skmbgI+CDgn+l//2KBAIF7oQo+oKNsAX/yrx420BSGjmVFzrGbWLOFdY2A6Y= X-Received: by 2002:a9d:bb6:: with SMTP id 51mr23874409oth.158.1573508123000; Mon, 11 Nov 2019 13:35:23 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> In-Reply-To: From: Tim Wicinski Date: Mon, 11 Nov 2019 16:35:12 -0500 Message-ID: To: Alessandro Vesely Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b902b2059718e851" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 21:35:26 -0000 --000000000000b902b2059718e851 Content-Type: text/plain; charset="UTF-8" > > If it were possible to infer OD from some kind of DNS record (or from RDAP > responses, for another way) then we'd have a tool alternative to the PSL. > That > proves that the concept of OD is independent of the PSL, doesn'it? > Over in DNSOP we're been working with the authors on this Related Domains draft https://datatracker.ietf.org/doc/draft-brotman-rdbd/ which defines a mechanism where two domains can state they are related, or not related via DNS records. What one wishes to use this information is left to them. It would be great to get y'all giving feedback Tim On Mon, Nov 11, 2019 at 3:43 PM Alessandro Vesely wrote: > On Mon 11/Nov/2019 19:31:52 +0100 Kurt Andersen (b) wrote: > > On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely > wrote: > > > >> For various reasons, large organizations administer many apparently > >> unrelated domains. For example, _dmarc.youtube.com has a rua mailto > >> ending in @google.com. We cannot infer an OD from that, but I think > the > >> concept is clear.>> > > > > I don't think this has anything to do with the PSD proposal either. Why > do > > you bring it up? > > > If it were possible to infer OD from some kind of DNS record (or from RDAP > responses, for another way) then we'd have a tool alternative to the PSL. > That > proves that the concept of OD is independent of the PSL, doesn'it? > > > >>> As to the proposed "let's run this as an experiment pending DMARCbis", > >>> I don't see how that satisfies Dave's concern about creating new work > >>> for receivers in order to help a small set of domain (realm) owners. > I'm > >>> not opposed to it, but I just don't see how this solves the issue.>> > >> Isn't that an ICANN problem? For the time being, dig _dmarc.bank txt > >> returns an empty NOERROR response, while _dmarc.gov.uk returns a valid > >> record. The latter is a Nominet, already solved problem, AFAICS.>> > > > > If it was a solved problem, then we would not need a PSD (or realm) I-D > and > > this whole discussion would be moot. What ICANN does and does not allow > is > > out of scope for the IETF/protocol work (though I do acknowledge that > ICANN > > may consider protocol factors when making decisions - or I would hope > that > > they would). > > > Oh, you meant the receivers burden of an extra lookup? Sorry, I though it > was > about the need for each OD to opt out by defining its own DMARC record, > lest > have reports delivered to the realm. In the latter sense, Nominet solved > the > problem of what rights has gov.uk on domains below it. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000b902b2059718e851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If it were possible to infer OD from some kind of DNS record (or = from RDAP
responses, for another way) then we'd have a tool alternat= ive to the PSL.=C2=A0 That
proves that the concept of OD is independent = of the PSL, doesn'it?

Over in DNSOP= we're been working with the authors on this Related Domains draft


which defines a mechanism where two domains can= state they are related, or not related via DNS records.=C2=A0
Wh= at one wishes to use this information is left to them.

=
It would be great to get y'all giving feedback

Tim


On Mon, Nov 11, 2019 at 3:4= 3 PM Alessandro Vesely <vesely@tana.it= > wrote:
On Mon 11/Nov/2019 19:31:52 +0100= Kurt Andersen (b) wrote:
> On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely <vesely@tana.it> wrote:
>
>> For various reasons, large organizations administer many apparentl= y
>> unrelated domains.=C2=A0 For example, _dmarc.youtube.com has a = rua mailto
>> ending in @google.com.=C2=A0 We cannot infer an OD from that, but I th= ink the
>> concept is clear.>>
>
> I don't think this has anything to do with the PSD proposal either= . Why do
> you bring it up?


If it were possible to infer OD from some kind of DNS record (or from RDAP<= br> responses, for another way) then we'd have a tool alternative to the PS= L.=C2=A0 That
proves that the concept of OD is independent of the PSL, doesn'it?


>>> As to the proposed "let's run this as an experiment p= ending DMARCbis",
>>> I don't see how that satisfies Dave's concern about cr= eating new work
>>> for receivers in order to help a small set of domain (realm) o= wners. I'm
>>> not opposed to it, but I just don't see how this solves th= e issue.>>
>> Isn't that an ICANN problem?=C2=A0 For the time being, dig _dm= arc.bank txt
>> returns an empty NOERROR response, while _dmarc.gov.uk returns a val= id
>> record. The latter is a Nominet, already solved problem, AFAICS.&g= t;>
>
> If it was a solved problem, then we would not need a PSD (or realm) I-= D and
> this whole discussion would be moot. What ICANN does and does not allo= w is
> out of scope for the IETF/protocol work (though I do acknowledge that = ICANN
> may consider protocol factors when making decisions - or I would hope = that
> they would).


Oh, you meant the receivers burden of an extra lookup?=C2=A0 Sorry, I thoug= h it was
about the need for each OD to opt out by defining its own DMARC record, les= t
have reports delivered to the realm.=C2=A0 In the latter sense, Nominet sol= ved the
problem of what rights has gov.uk on domains below it.


Best
Ale
--
















_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000b902b2059718e851-- From nobody Mon Nov 11 14:21:35 2019 Return-Path: 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 C047A1201E0 for ; Mon, 11 Nov 2019 14:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FZrVkT-vt2D4 for ; Mon, 11 Nov 2019 14:21:32 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 B665812010D for ; Mon, 11 Nov 2019 14:21:21 -0800 (PST) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id xABMLj9A008065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2019 14:21:45 -0800 To: "Kurt Andersen (b)" , Tim Wicinski Cc: IETF DMARC WG , Scott Kitterman References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> Date: Mon, 11 Nov 2019 14:21:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------612D8FC2A5296B5AFC4D2BFD" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 22:21:34 -0000 This is a multi-part message in MIME format. --------------612D8FC2A5296B5AFC4D2BFD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/11/2019 7:46 AM, Kurt Andersen (b) wrote: > I do have a problem with the conflation of the org domain with a > super-organizational "realm" (?) that may impose conditions upon > organizations that fall within their jurisdictional purview. This goes to the essential challenge of a proposal like PSD.  It embodies a particular model, in the absence of clarity about the model or broad-based discussion of its appropriateness.  (Note, for example, that my review offered some discussion of that sort but got no comment on that discussion.) In effect, it creates a strategic solution -- that is, a long-lived and embedded mechanism -- without a clear and broad understanding of the organizational space it is working in. On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote: > * add text to the PSD draft making it clear that what it's describing > is an experiment whose outcome will be taken only as feedback to the > revision of the standard (i.e., this is not intended to be the final > form of anything), and it is not intended to be deployed outside of > the experiment's participants; Forgive me, but while everyone involved in this has extensive experience and is trying to solve a real and serious issue, this is an astonishingly naive view. The IETF does standards, not experiments.  Not /real/ experiments.  What it calls an experiment mostly serves as market testing, with a smidgen of engineering tuning later.  For the most part, IETF experiments produce an accepted/failed/needs-small-revisions range of results.  What it does /not/ produce is results along the lines of "that was interesting, now let's start fresh and do the real standard." Perhaps there are exampls of IETF experiments that have permitted entirely starting over, but mostly those only happen when there is a complete failure, and those typically are called experiments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------612D8FC2A5296B5AFC4D2BFD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/11/2019 7:46 AM, Kurt Andersen (b) wrote:
I do have a problem with the conflation of the org domain with a super-organizational "realm" (?) that may impose conditions upon organizations that fall within their jurisdictional purview.


This goes to the essential challenge of a proposal like PSD.  It embodies a particular model, in the absence of clarity about the model or broad-based discussion of its appropriateness.  (Note, for example, that my review offered some discussion of that sort but got no comment on that discussion.)

In effect, it creates a strategic solution -- that is, a long-lived and embedded mechanism -- without a clear and broad understanding of the organizational space it is working in. 


On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
* add text to the PSD draft making it clear that what it's describing is an experiment whose outcome will be taken only as feedback to the revision of the standard (i.e., this is not intended to be the final form of anything), and it is not intended to be deployed outside of the experiment's participants;


Forgive me, but while everyone involved in this has extensive experience and is trying to solve a real and serious issue, this is an astonishingly naive view.

The IETF does standards, not experiments.  Not /real/ experiments.  What it calls an experiment mostly serves as market testing, with a smidgen of engineering tuning later.  For the most part, IETF experiments produce an accepted/failed/needs-small-revisions range of results.  What it does /not/ produce is results along the lines of "that was interesting, now let's start fresh and do the real standard."

Perhaps there are exampls of IETF experiments that have permitted entirely starting over, but mostly those only happen when there is a complete failure, and those typically are called experiments.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------612D8FC2A5296B5AFC4D2BFD-- From nobody Mon Nov 11 14:27:25 2019 Return-Path: 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 33E211201A3 for ; Mon, 11 Nov 2019 14:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2oDgeyJfO2P7 for ; Mon, 11 Nov 2019 14:27:22 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 2D9AF120122 for ; Mon, 11 Nov 2019 14:27:17 -0800 (PST) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id xABMRdCD008398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2019 14:27:40 -0800 To: dcrocker@bbiw.net, "Kurt Andersen (b)" , Tim Wicinski Cc: IETF DMARC WG , Scott Kitterman References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <66571eaf-b8dc-aa6e-4cbe-c6da0b27b2de@dcrocker.net> Date: Mon, 11 Nov 2019 14:27:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> Content-Type: multipart/alternative; boundary="------------0E49791CC63996916DD472E3" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 22:27:23 -0000 This is a multi-part message in MIME format. --------------0E49791CC63996916DD472E3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/11/2019 2:21 PM, Dave Crocker wrote: > and those typically are called experiments. /not/ called. (sorry) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------0E49791CC63996916DD472E3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 11/11/2019 2:21 PM, Dave Crocker wrote:
and those typically are called experiments.

/not/ called.


(sorry)


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------0E49791CC63996916DD472E3-- From nobody Mon Nov 11 14:31:17 2019 Return-Path: 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 193651201A3 for ; Mon, 11 Nov 2019 14:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=xy56hIOD; dkim=pass (1536-bit key) header.d=taugh.com header.b=UP+khSct 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 O74Mazr6a5wJ for ; Mon, 11 Nov 2019 14:31:13 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 83D87120133 for ; Mon, 11 Nov 2019 14:31:13 -0800 (PST) Received: (qmail 60813 invoked from network); 11 Nov 2019 22:31:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ed8a.5dc9e12f.k1911; i=printer-iecc.com@submit.iecc.com; bh=ON5W0PRWZVbU3Zd81lTbbhaA9YnE+k5k6HW6W5fj848=; b=xy56hIODCLyBGgirywoYR/D5l7PYyp3tU97qsBbJmRZpJRWTVHI3QfxTmis00Wwkyr7RSrBDWHECD4WCbMBacUcsKxJotwbFa5v/V4zUwYVZjkbWwk9YMbc1a6mhI5HoEjTT9XUtErEyMtkGFGCRHTbjxrO4KEbfjig4VaWreSMsbrn7JiVtZ77RLTkwIqLN0HxMqet/BWavswxIi9wN1kkKKBApEUYmJVX8RIRK/Ynn+dk092LZ3Z/V2j9+QXVb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ed8a.5dc9e12f.k1911; olt=printer-iecc.com@submit.iecc.com; bh=ON5W0PRWZVbU3Zd81lTbbhaA9YnE+k5k6HW6W5fj848=; b=UP+khSctusZckqM+hjceVD/92vpyyi9O3SxsEjBHbIcNak5fj24pfTTeeCBBjsCo02Jx8ZI1j6TUwIs8+fAqOHuUcz2tkru/LQbAf3UtxKfNQpERiNqN8vAFsHfSw1yLybs/WLFSR7lIh4t+30rjElw/ufOeHvt1doJ68gWb18JUYZP1PySIehVMBnj7gZnBhvhYkRX3mF3jUoJHmbGj1ARmwl7mwErVvOBDLHzAU1UgrADF3wfQZVm1B4Hk7aGI Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 11 Nov 2019 22:31:11 -0000 Received: by ary.qy (Postfix, from userid 501) id D6663EA2E32; Mon, 11 Nov 2019 17:31:10 -0500 (EST) Date: 11 Nov 2019 17:31:10 -0500 Message-Id: <20191111223110.D6663EA2E32@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 22:31:15 -0000 In article you write: >https://datatracker.ietf.org/doc/draft-brotman-rdbd/ > >which defines a mechanism where two domains can state they are related, or >not related via DNS records. >What one wishes to use this information is left to them. > >It would be great to get y'all giving feedback If it's useful at all, which I don't think it is, it's definitely not useful for PSD since it's intended to describe cross-tree relationships, not the vertical ones that the PSL identifies and that PSD needs. This proposal also invents yet another signature scheme, presumably for the benefit of people who don't think DNSSEC will ever work, which is strange since the lead author works for Comcast who have what is probably the world's biggest set resolvers that validate and use DNSSEC and DANE. R's, John PS: It's not that I think there are no cross-tree relationships to describe, it's that we know from Andrew Sullivan's failed SOPA proposal that doing it one label at a time rather than subtree to subtree isn't viable. From nobody Mon Nov 11 14:47:53 2019 Return-Path: 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 D8F94120803 for ; Mon, 11 Nov 2019 14:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=gKz/dgvb; dkim=pass (1536-bit key) header.d=taugh.com header.b=kSxPP1vQ 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 RvmR7v6L4Dh6 for ; Mon, 11 Nov 2019 14:47:50 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 3DE90120122 for ; Mon, 11 Nov 2019 14:47:50 -0800 (PST) Received: (qmail 64469 invoked from network); 11 Nov 2019 22:47:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fbd3.5dc9e514.k1911; i=printer-iecc.com@submit.iecc.com; bh=DS6eYLdK3Yy39hRPiT3HKFnQZTKBlARw7O6y1OaVFNI=; b=gKz/dgvbAXJwS7J65JXoLo6D9tYUs+kOp8BPSVVJ86TCV1iNnaw3F7IKS+d5Df/5zYZzvZ7SfWZmcU5udQ9wJKSb3QjZfgQHxeRhnDT581YZuK84mehzqwLYxw7BBCROrxzX0cjQ/KZF3Z+A+NI+swikyH8ZHj1S8VDsw3fzEM7ORZgBdE6mZd1qaWQ4qhNA2dg+z2R2YVRdfXoNjYdpWLUCg/mY7ikaKc2Ce5cGV59sTL8P1h37nRu21mg3P5Gb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fbd3.5dc9e514.k1911; olt=printer-iecc.com@submit.iecc.com; bh=DS6eYLdK3Yy39hRPiT3HKFnQZTKBlARw7O6y1OaVFNI=; b=kSxPP1vQ++VtxnhpStKvxUy3dABtCRfUNVlHLaOTMNp57GSuUychelpL1lUrMsJ2Q4aqEI9oUNt+/VnxwaQQrAf8Knl883+f4ft3oTrdFyI0PRtFJneuuTkvhcYxMW0jsbRvTGs2ZaIpVreNkUCWcCsy1no7noj3oxoRILchBa0+TSxEvkRiIKQtpNFYzQxjKtggXmL56vrhTvilT9QE0C45ql2kuBXo8k1DYgjUaTs7B6pHsn427DXic65rl5Ox Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 11 Nov 2019 22:47:48 -0000 Received: by ary.qy (Postfix, from userid 501) id 2CE39EA3394; Mon, 11 Nov 2019 17:47:47 -0500 (EST) Date: 11 Nov 2019 17:47:47 -0500 Message-Id: <20191111224748.2CE39EA3394@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 22:47:52 -0000 In article <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> you write: >This goes to the essential challenge of a proposal like PSD.  It >embodies a particular model, in the absence of clarity about the model >or broad-based discussion of its appropriateness.  (Note, for example, >that my review offered some discussion of that sort but got no comment >on that discussion.) > >In effect, it creates a strategic solution -- that is, a long-lived and >embedded mechanism -- without a clear and broad understanding of the >organizational space it is working in. I've been talking to some of the PSL people, and they seem really stuck. They know they don't have a way to describe vanity single-registrant TLDs, and I don't even want to suggest that they might want to describe something like PSD, with a super-authority above a suffix boundary. R's, John From nobody Mon Nov 11 14:51:52 2019 Return-Path: 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 0BFAE120048 for ; Mon, 11 Nov 2019 14:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.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 rqmaCb_WDqjI for ; Mon, 11 Nov 2019 14:51:47 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4436312002E for ; Mon, 11 Nov 2019 14:51:37 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id i13so15125442ioj.5 for ; Mon, 11 Nov 2019 14:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IsoBwdgyo5HTnvNBcoUdXf5bvEGr/5XAccDZdrLQueI=; b=VmP1djuSfQd72PUbmVH2Zpy4d1qS5T4OL1uaPlPA/PZhDY7sbr/p7OH+J5YxpiXKvK Arth6gKMGLjBV+weqy0Njfaoyd7WS6JUuMUlF6PLPK+iFSrq1zabjCkMI/WLUy+Sx83X IoeNShPcNvWAWsrEb4rHHUm2ZPrIhA5tPdM5c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IsoBwdgyo5HTnvNBcoUdXf5bvEGr/5XAccDZdrLQueI=; b=PhqYo4zRNzs0rn7c7a5SjohcGmFLb3jWyqJJRHMDwbtfNa3HRyQhMTS0IQ6aZ2veXv bgkohfJ6RroUFKl7kgpdHWCCoHtEdMaBNHTGPzxzNBExLGYZUSg+MT6GK+lM2P5G9Z/8 a1rEfNcnrKuzkt+yD8VSU540oJlcrPscW1OfJE19sJcHNDqvkDdlOcPHxWfhH+wr7mUB N6txTVxMQnQZPRmrj3MbjggaRMch+IFat+gHlVvUZEkeimbIp7ECgluFX0eFvuSWzGgS iy5h5XR6wJ8UuPGcp6jSStVQ1Hlp1r5CXee0zjbH24PxSCOY3iYD6KCoijmGLyuE3Y/P kj6g== X-Gm-Message-State: APjAAAV1Z/VUvp/DjJW3OX8rSZNSMETeRU4YMzPiXla+WQ68GdSQmB+m 4i9OlTyh5toWt3FHQDEpykdMyF0xYtUfytVVyES1Cqh3Pd4= X-Google-Smtp-Source: APXvYqyWSBPxIRtl8B1bVx41hjzAc332UkncvVysnHZJjTylbXpo4Og+AQRxq3aSJVD13P6k5uSQDhOvhaVjIdbh7F0= X-Received: by 2002:a6b:d81a:: with SMTP id y26mr17288973iob.23.1573512696328; Mon, 11 Nov 2019 14:51:36 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 11 Nov 2019 14:51:17 -0800 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000508ffe059719f971" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Mon, 11 Nov 2019 22:51:51 -0000 --000000000000508ffe059719f971 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 12:43 PM Alessandro Vesely wrote: > > about the need for each OD to opt out by defining its own DMARC record, > lest > have reports delivered to the realm. In the latter sense, Nominet solved > the > problem of what rights has gov.uk on domains below it. > Requiring "trick" authoritative name servers at the realm level is a/the solution?!? If so, let's just drop all this I-D noise and get it all done. That would also solve .bank's problem because they would not have to "publish" any records contravening ICANN's requirements. They would only have to "serve" them as responses. --Kurt --000000000000508ffe059719f971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 11, 2019 at 12:43 PM Alessand= ro Vesely <vesely@tana.it> wrot= e:

about the need for each OD to opt out by defining its own= DMARC record, lest
have reports delivered to the realm.=C2=A0 In the latter sense, Nominet sol= ved the
problem of what rights has gov.uk on domains below it.

Requiring "trick" authoritative name servers at the realm= level is a/the solution?!? If so, let's just drop all this I-D noise a= nd get it all done. That would also solve .bank's problem because they = would not have to "publish" any records contravening ICANN's = requirements. They would only have to "serve" them as responses.<= /div>

--Kurt=C2=A0
--000000000000508ffe059719f971-- From nobody Mon Nov 11 22:59:35 2019 Return-Path: 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 092A4120133 for ; Mon, 11 Nov 2019 22:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk 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 LiVTz62urx6j for ; Mon, 11 Nov 2019 22:59:12 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100139.outbound.protection.outlook.com [40.107.10.139]) (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 E46FE1200A4 for ; Mon, 11 Nov 2019 22:59:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YOmw4CL0qVRL1KuQ5j47V9VT8Qf0R2L3czSyw0vOSO9RcFdv/xOc1bFP3cgnDYEkL10XT39U0s9v3GQuoft6FEmazvdqCzpFg7rHwCNOeAKbnHkvoZn/KHaejcnJSL1ogcegSl7OhMoDOO8si1EUuS2cIi9Ngf8uxJkzUDPPUusjQqYECzfouRXQpZeP2bWW3vNxxQ3z/YGh8fBna6Fi0L4QX3noswYkG/eQe0BYdnbNgQQ77g5T1/BC3oMKWe9dgTas4vMLzku74JLdRJATdj4cOL3oFGsW36ItvP6SeqVa8Kpje4iTd1DP+Zz8HYkIC+zZcATHEfSsvr4fFTOIiA== 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=osYXV0cgrpWOQJRVCaD/juO6w7Tnz0c1KIdJw13EQus=; b=DvBe82hPq59TXP9YKCquuIrQgA1Kw92ipqFPg9VGMoB7lWwYrH2ueRC/FpsdNTfHxMy52CBN4cXJZFZUFLMiqKKju8yPbhy4Qb8B4vVZ+o7zpXaDUpXpHOzUCSrejNL8hX802lu4LGgheB/N08VdhX2kGnYdu42vtiZsyDauuQ6uXVacXeaL7lnAyGR1fgdwTSVPhaWkNziXku8BGwdtG6B2ItBqXi0aoBJNfjYOgcMiZL+j/5UJ1/McIvEU3mlIa3Mu8aUAfkj87+QmDBKAeVmx72BTJdpG8vqE7J0obfHK3NTEONGWfUI2Y1eokMSsdXQ+DV68QJwCvoeN4dujDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=osYXV0cgrpWOQJRVCaD/juO6w7Tnz0c1KIdJw13EQus=; b=EzKrGQOqCc6ITVlh0wBG+P2gHswv3SxCPMnNRDlPfMW/P9ZVjDHWwlcFwVH+GpmE/lYw2G9APE/IO5I6NTpIfiP39VdmO+MUmRb2L3qxpdi1OY54mOc8bnKr/l9vBzOOqLlFw70D8cb21NcWPA93NzEa0uk4a6ppDGd9uyF9a5s= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB1902.GBRP123.PROD.OUTLOOK.COM (20.176.155.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.25; Tue, 12 Nov 2019 06:59:09 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::55de:86ea:53e9:92ef]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::55de:86ea:53e9:92ef%6]) with mapi id 15.20.2430.027; Tue, 12 Nov 2019 06:59:09 +0000 From: Ian Levy To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Comment on draft-ietf-dmarc-psd Thread-Index: AQHVUkRUHW06UOOZ+kq6kqLLLMMrLqcaPC6AgANurWOAaHWPgIAADzIAgAAY2wCAAGFPgIAAIrUAgADa9BI= Date: Tue, 12 Nov 2019 06:59:09 +0000 Message-ID: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> , <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> In-Reply-To: <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.140.78.31] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61d7e2ff-96f9-4bdc-7fe1-08d7673dd159 x-ms-traffictypediagnostic: LO2P123MB1902: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(39850400004)(366004)(376002)(346002)(189003)(199004)(229853002)(8676002)(81156014)(446003)(76176011)(71200400001)(7696005)(71190400001)(11346002)(486006)(476003)(5660300002)(44832011)(102836004)(99286004)(76116006)(110136005)(316002)(66946007)(33656002)(52536014)(606006)(81166006)(2906002)(66446008)(64756008)(66556008)(66476007)(14444005)(256004)(186003)(74316002)(966005)(6246003)(8936002)(6116002)(26005)(9686003)(3846002)(7736002)(25786009)(6436002)(86362001)(6506007)(55236004)(6306002)(54896002)(55016002)(2501003)(53546011)(45080400002)(478600001)(236005)(14454004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB1902; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6r6+Zh0y8pPEK00Nzd8HdFCxcroQuV6q+Fg2dn0SrA3vTMX49Zk3SjyIeeGksjFImrzLaMYX6PpU0RQwPorPbQ+RIQoTudZFTCPeRTaSzgzNruAJdQY6VDtD0wzRLixWdfL+HklTRPxf7vVgR7jIKjNc9vVXsagP0WZrbwjjVSC430RbtR4L2g4q3lGutK03kAvsnw9TD8MfJPJAdKl6S3ExNnJ7v3hrHPKYAdEEhTcUaO1Lk72z5zQLUfXdpqx9idieACPj905Jr2AMH7shA7SgXnqUzQGCv5yDgL7DxEOGr57xtCggOXvveZndKVXfkVzwa0VdVKzIFPwg1PXnDYVYHOHCSlZN3P606D+vLSqFJXm9kcx5zHjYcmNLx4O2plrSPjPtPRdKrQ8OitzWZGET1YQE9OoWiD1WrKBFFON0TpC7ahbAasNU5QBNcKeSrbuTKoHb8gV4sgAdJxgHGeI7bZVPRC5oijgQrGNR7JE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB2285B674B32C689CE2C1455DC9770LO2P123MB2285GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 61d7e2ff-96f9-4bdc-7fe1-08d7673dd159 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 06:59:09.8874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 494LYrYWmN87cTpQG3FjMHgzBIlbSCXtb+deanhws5DoxO7wfaKel6hJ8MI3KwUYJWYnk65gOxz+L68IJt0p2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1902 Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Tue, 12 Nov 2019 06:59:16 -0000 --_000_LO2P123MB2285B674B32C689CE2C1455DC9770LO2P123MB2285GBRP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > while _dmarc.gov.uk returns a valid record. The > latter is a Nominet, already solved problem, AFAICS. I can speak authoritatively about this. What we=92ve got is an evil, hacky = kludge that has some weird side effects (since we respond to *any* non exis= tent sub domain, not just DMARC and SPF related ones). It=92s just about pa= ssable as an interim, but we believe we need a better, targeted solution al= ong the lines of Scott=92s draft. Ta. I. =97 Dr Ian Levy Technical Director National Cyber Security Centre ian@ncsc.gov.uk ________________________________ From: dmarc on behalf of Alessandro Vesely Sent: Monday, November 11, 2019 5:50:30 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote: > > I don't think that it is fair to say that anyone who refers to the org do= main > concept as cited in the DMARC spec is necessarily invoking the PSL. Agreed. The PSL just happens to be the only valid tool to do that. For various reasons, large organizations administer many apparently unrelat= ed domains. For example, _dmarc.youtube.com has a rua mailto ending in @google.com. We cannot infer an OD from that, but I think the concept is c= lear. > I do have a problem with the conflation of the org domain with a > super-organizational "realm" (?) that may impose conditions upon organiza= tions > that fall within their jurisdictional purview. My main concerns are with = the > potential usurpation of the org domain's policy declaration rights. "Movi= ng" > the org domain up one level disenfranchises the organizations and that is= the > wrong thing to do IMO. The I-D definitions are clear enough. Section 2.5, in particular, prevents= the conflation neatly. > As to the proposed "let's run this as an experiment pending DMARCbis", I = don't > see how that satisfies Dave's concern about creating new work for receive= rs in > order to help a small set of domain (realm) owners. I'm not opposed to it= , but > I just don't see how this solves the issue. Isn't that an ICANN problem? For the time being, dig _dmarc.bank txt retur= ns an empty NOERROR response, while _dmarc.gov.uk returns a valid record. The latter is a Nominet, already solved problem, AFAICS. Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Cian.levy%40ncsc.gov= .uk%7C63443737a62a47a65f1008d766cfae3a%7C14aa5744ece1474ea2d734f46dda64a1%7= C0%7C0%7C637090914473667320&sdata=3DcOeg7QPSBP0Fzldb8a0RE3ZqsIrBmVG%2B4= B2HOrCopaQ%3D&reserved=3D0 This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB2285B674B32C689CE2C1455DC9770LO2P123MB2285GBRP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
> while _dmarc.gov.uk returns a valid rec= ord. The
> latter is a Nominet, already solved pro= blem, AFAICS.

I can speak authoritatively about this. What= we=92ve got is an evil, hacky kludge that has some weird side effects (sin= ce we respond to *any* non existent sub domain, not just DMARC and SPF rela= ted ones). It=92s just about passable as an interim, but we believe we need a better, targeted solution along th= e lines of Scott=92s draft.

Ta.

I.

=97
Dr Ian Levy
Technical Director
National Cyber Security Centre
ian@ncsc.gov.uk
From: dmarc <dmarc-bounc= es@ietf.org> on behalf of Alessandro Vesely <vesely@tana.it>
Sent: Monday, November 11, 2019 5:50:30 PM
To: dmarc@ietf.org <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
 
On Mon 11/Nov/2019 16:46:17 +0100 Kurt Anderse= n (b) wrote:
>
> I don't think that it is fair to say that anyone who refers to the org= domain
> concept as cited in the DMARC spec is necessarily invoking the PSL.

Agreed.  The PSL just happens to be the only valid tool to do that.
For various reasons, large organizations administer many apparently unrelat= ed
domains.  For example, _dmarc.youtube.com has a rua mailto ending in @google.com.  We cannot infer an OD from that, but I think the concept= is clear.


> I do have a problem with the conflation of the org domain with a
> super-organizational "realm" (?) that may impose conditions = upon organizations
> that fall within their jurisdictional purview. My main concerns are wi= th the
> potential usurpation of the org domain's policy declaration rights. &q= uot;Moving"
> the org domain up one level disenfranchises the organizations and that= is the
> wrong thing to do IMO.


The I-D definitions are clear enough.  Section 2.5, in particular, pre= vents the
conflation neatly.


> As to the proposed "let's run this as an experiment pending DMARC= bis", I don't
> see how that satisfies Dave's concern about creating new work for rece= ivers in
> order to help a small set of domain (realm) owners. I'm not opposed to= it, but
> I just don't see how this solves the issue.


Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt = returns
an empty NOERROR response, while _dmarc.gov.uk returns a valid record. = ; The
latter is a Nominet, already solved problem, AFAICS.


Best
Ale
--














_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://eur03.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Fli= stinfo%2Fdmarc&amp;data=3D02%7C01%7Cian.levy%40ncsc.gov.uk%7C63443737a6= 2a47a65f1008d766cfae3a%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6370909= 14473667320&amp;sdata=3DcOeg7QPSBP0Fzldb8a0RE3ZqsIrBmVG%2B4B2HOrCopaQ%3= D&amp;reserved=3D0
This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9
--_000_LO2P123MB2285B674B32C689CE2C1455DC9770LO2P123MB2285GBRP_-- From nobody Tue Nov 12 00:16:46 2019 Return-Path: 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 108BF120169 for ; Tue, 12 Nov 2019 00:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 BoXeXy7bmGlz for ; Tue, 12 Nov 2019 00:16:42 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C1F120046 for ; Tue, 12 Nov 2019 00:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573546598; bh=eHQQGjunCrh5uNx3GuNzl4GCsvIMQnVKV63ZlpnOAP8=; l=1520; h=To:References:From:Date:In-Reply-To; b=ADIkhJ0NpZi8lS2DvTAtd+tEWc7gBXaLCn7uFURmhpO7y58cygKTCcF8dA12nyEwj pRhd3erdwSvugZrBV+//l+T+EETV/RYazJwolXPqgJaxa1SNd9HiHE5xVsp62ChhQn MfNeUA9Idqx71z7yn0m6jB7bFTDOwCBG4Vp4X43sL/qs0TA/YGzeBv1tLownZ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC073.000000005DCA6A66.0000526E; Tue, 12 Nov 2019 09:16:38 +0100 To: dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Tue, 12 Nov 2019 09:16:38 +0100 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] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Tue, 12 Nov 2019 08:16:44 -0000 On Tue 12/Nov/2019 07:59:09 +0100 Ian Levy wrote: >> while _dmarc.gov.uk returns a valid record. The latter is a Nominet, >> already solved problem, AFAICS.> > I can speak authoritatively about this. What we’ve got is an evil, hacky > kludge that has some weird side effects (since we respond to *any* non > existent sub domain, not just DMARC and SPF related ones). It’s just about > passable as an interim, but we believe we need a better, targeted solution > along the lines of Scott’s draft. Thank you for chiming in. Let me pinpoint that the hack you talk about is the use of wildcards, which Scott's draft tries to fix with the np= tag. That's a protocol issue. At a PSO level, someone decided that gov.uk can publish TXT records which may affect all of the downward tree --solved. The bank PSO cannot do that, and we (the WG) look forward to ICANN allowing it --not yet solved. The com PSO cannot do it either, but I'd guess lots of people trust that ICANN will never allow it. I hope I've now clarified what I mean by "ICANN problem". Scott's draft cannot solve it, albeit it nearly touches on the point at the end of the intro. It is not a protocol problem. It involves PSO-registrants agreements, and ICANN managing that stuff. There is not much we (the WG) can do, except hoping that ICANN may consider protocol factors when making decisions. As an Internet user, I'd welcome diversity among TLDs, as numerousness without diversity becomes just annoying. Best Ale -- From nobody Tue Nov 12 06:12:46 2019 Return-Path: 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 7CB1512004C for ; Tue, 12 Nov 2019 06:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk 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 GzkSr1OJQCDf for ; Tue, 12 Nov 2019 06:12:42 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100109.outbound.protection.outlook.com [40.107.10.109]) (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 EC2CF120033 for ; Tue, 12 Nov 2019 06:12:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T2L+9yJ5v1KQ4DP62rT4x0r9Ec2o41OACaTuyFDUXHIZpsyyE583Jjnwx/mSOPoVdA9OFy82NiA2qALzNUKpFu9ADjanwY+70vBvgKO9Ie2kMgw+HVWnNbh3BuJoCgpZh1ZZ0FbVU/l671Uo58PqknQEuMV/KBsO8vf8j6dcJbl/CeWD/gifOOToexYhjQPkPZ4T7w8c2FKfBZMTdJmnLiCVRZGYPkt382iFHZgLRu3jQmL2oYOG9Lu8M1sJDO1rW4XzHV65J0yk7C5I+EXa0iyeUdfxSnJ/78X18EnoaH+2hRHNtv0hp5DsF/cLIK++XmRj214HOvAbDvijKuxD1g== 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=72/SfEBnHJJ7jH3BQZMrtAwe/gP05Ztp705PETtZt8Q=; b=dE5WL2m7RGv1oVcmH62Gt6PK8+I8hLSnPlzvooci59sFgv3sZ1m8mhzZfHlGB2U8An3e9dxejqhIRMxYo6ZGXNcKDtC/q+iHUrsB7VCiMST1PrSrwKLhGGT6HCZVqBQouNQe/Iev8spL+Mj3bTLDB6sHNvLOg1LXABadjodt4UoOqju1GxMLsWufuMKKUllHDsJBESIN59FqdQk5INUGsWVuA9ngOKmqGYk9/Sz/fnMcGtsfwBMvcsvO5yISENO/87W0eFFLkTaMK44TgsMYoNgM2ffXcS9Ew09oS7UpK9hv5s54+UpwHTK3xr/KDhq+8GthapeGGrtkwW7HorZg4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=72/SfEBnHJJ7jH3BQZMrtAwe/gP05Ztp705PETtZt8Q=; b=I3V5hktmpjlfulAuF4IzxtV/7dTdaZ47BzSzpz0DucsTU7D+hS8UTLzIECKwtGdu4k6UfVZZJo3nzhzACh3o89VKo8iig4rMSVg7HhIVKOFjVvXN/YVOHwgObL2nXnQAitm+x3ySv4qH973xqvc+iB42EtpQwmafYgJh0e/dygI= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB1952.GBRP123.PROD.OUTLOOK.COM (20.176.156.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.25; Tue, 12 Nov 2019 14:12:39 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::55de:86ea:53e9:92ef]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::55de:86ea:53e9:92ef%6]) with mapi id 15.20.2430.027; Tue, 12 Nov 2019 14:12:39 +0000 From: Ian Levy To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Comment on draft-ietf-dmarc-psd Thread-Index: AQHVUkRUHW06UOOZ+kq6kqLLLMMrLqcaPC6AgANurWOAaHWPgIAADzIAgAAY2wCAAGFPgIAAIrUAgADa9BKAABcLAIAAYgkQ Date: Tue, 12 Nov 2019 14:12:39 +0000 Message-ID: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.140.78.31] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fd1cb0d-1289-46e4-36f9-08d7677a6018 x-ms-traffictypediagnostic: LO2P123MB1952: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(396003)(39850400004)(366004)(376002)(189003)(199004)(13464003)(74316002)(9686003)(8936002)(6116002)(25786009)(3846002)(6246003)(305945005)(966005)(7736002)(26005)(53546011)(478600001)(45080400002)(6306002)(55016002)(2501003)(66066001)(14454004)(6436002)(66574012)(55236004)(6506007)(86362001)(81156014)(7696005)(486006)(186003)(44832011)(99286004)(5660300002)(476003)(102836004)(316002)(229853002)(8676002)(76176011)(71190400001)(71200400001)(33656002)(52536014)(11346002)(66946007)(14444005)(66476007)(66556008)(64756008)(66446008)(2906002)(256004)(81166006)(76116006)(110136005)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB1952; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ebELZKRx/j1Y1ysrl19NkI6xw31BAlNTHqtBDagpdT4d/AR5yrbIdZitDT5V4ag5TBy4h+onhf2Sr8V0iYccS9PTDPrkNVohAQxzF5RB+IM1DMwVNFFxrGvMUQ9MNpOwu7BbYaCywo2YM6s00XngbG3C2aguVBQ5WoNmws/wypyobjgN06ONHOovyP8/qiX0DWUIrtxNuqbMMhNzfXuJEpyk/T8nGxzG5iLxHca55rV15ZOG5GyHFgYxsFnU/mq1ay1qt3WVBczRrf3WfkMPrqIB1Pb06rS1QK1VJkzVfQVU4FAp1AB6TMCuEXyISiQ7cPpBCGXs758N4iWWWvaBqxhgAE8RdZF2Wf9bY0G7KHm67jTYTlETmOMCQvps1C+XDzB9Vi+N39kfPExihehha1mSzYWEs8Pn7DfM8KXnSjb7CBxgiOfWb1BKKVzvYwT06r1K8GgZh7xvmyK14+WyuTKLCcSC7qfAWXd9mu8STps= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 5fd1cb0d-1289-46e4-36f9-08d7677a6018 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 14:12:39.0945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xnc9c4xh+t//3Wimi17uLPcUocizAHwqyjZt+XcNSx8Zanh8/QA8Qq+dYJIFxidS5Pjqs+O2CDJRvB7tzJ+qeQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1952 Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org 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: Tue, 12 Nov 2019 14:12:44 -0000 PiBMZXQgbWUgcGlucG9pbnQgdGhhdCB0aGUgaGFjayB5b3UgdGFsayBhYm91dCBpcyB0aGUgdXNl IG9mIHdpbGRjYXJkcywgd2hpY2ggU2NvdHQncyBkcmFmdCB0cmllcyB0byBmaXggd2l0aCB0aGUg bnA9IHRhZy4gIFRoYXQncyBhIHByb3RvY29sIGlzc3VlLg0KDQpGYWlyIHBvaW50LiBJIHdhcyBv bmx5IHRyeWluZyB0byBtYWtlIHN1cmUgdGhhdCBwZW9wbGUgZG9u4oCZdCB0YWtlIHdpbGRjYXJk cyBhcyBhIGxvbmcgdGVybSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0uIEluIG91ciBleHBlcmll bmNlLCB0aGV5J3JlIG5vdC4gDQoNCj4gQXQgYSBQU08gbGV2ZWwsIHNvbWVvbmUgZGVjaWRlZCB0 aGF0IGdvdi51ayBjYW4gcHVibGlzaCBUWFQgcmVjb3JkcyB3aGljaCBtYXkgYWZmZWN0IGFsbCBv ZiB0aGUgZG93bndhcmQgdHJlZSAtLXNvbHZlZC4gIA0KDQpUaGF0IHdhcyBtZS4gU3RpbGwgZG9u J3QgYWdyZWUgdGhhdCB0aGUgcHJvYmxlbSBpcyAnc29sdmVkJywgYnV0IEkgbWF5IGp1c3QgYmUg YmVpbmcgYSBwZWRhbnQgOi0pLg0KDQo+IFRoZSBiYW5rIFBTTyBjYW5ub3QgZG8gdGhhdCwgYW5k IHdlICh0aGUgV0cpIGxvb2sgZm9yd2FyZCB0byBJQ0FOTiBhbGxvd2luZyBpdCAtLW5vdCB5ZXQg c29sdmVkLiAgDQoNCkFncmVlZC4gDQoNCj4gSSBob3BlIEkndmUgbm93IGNsYXJpZmllZCB3aGF0 IEkgbWVhbiBieSAiSUNBTk4gcHJvYmxlbSIuDQoNClllcywgdGhhbmtzLiBJIHRoaW5rIHdlIGNh biwgYXMgdGhlIFdHLCBkbyBzb21ldGhpbmcgLSBhbmQgdGhhdCdzIHRvIG1ha2Uga25vd24gdG8g SUNBTk4gdGhlIHByb2JsZW0gd2UgYmVsaWV2ZSBleGlzdHMgYW5kIGhvdyB0aGVpciBjdXJyZW50 IHBvbGljeSBjb3VsZCBiZSBhbWVuZGVkIChzYWZlbHkpIHRvIGhlbHAgZml4IGl0LiBXZSdsbCBj ZXJ0YWlubHkgZG8gdGhhdCwgYnV0IEkga25vdyBvdXIgdm9pY2UgaXMgbm90IHN0cm9uZy4gQ29u c2lzdGVudCBtZXNzYWdpbmcgZnJvbSBwZW9wbGUgb24gdGhpcyBncm91cCB3b3VsZCBoZWxwLCBJ IGJlbGlldmUuIA0KDQpUYS4NCg0KSS4NCg0KLS0NCkRyIElhbiBMZXZ5DQpUZWNobmljYWwgRGly ZWN0b3INCk5hdGlvbmFsIEN5YmVyIFNlY3VyaXR5IENlbnRyZQ0KaWFuQG5jc2MuZ292LnVrDQoN ClN0YWZmIE9mZmljZXIgOiBLYXRlIEF0a2lucywga2F0ZS5hQG5jc2MuZ292LnVrDQoNCihJIHdv cmsgc3R1cGlkIGhvdXJzIGFuZCB3ZWlyZCB0aW1lcyDigJMgdGhhdCBkb2VzbuKAmXQgbWVhbiB5 b3UgaGF2ZSB0by4gSWYgdGhpcyBhcnJpdmVzIG91dHNpZGUgeW91ciBub3JtYWwgd29ya2luZyBo b3VycywgZG9u4oCZdCBmZWVsIGNvbXBlbGxlZCB0byByZXNwb25kIGltbWVkaWF0ZWx5ISkNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRtYXJjIDxkbWFyYy1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgQWxlc3NhbmRybyBWZXNlbHkNClNlbnQ6IDEyIE5vdmVtYmVy IDIwMTkgMDg6MTcNClRvOiBkbWFyY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRm XSBDb21tZW50IG9uIGRyYWZ0LWlldGYtZG1hcmMtcHNkDQoNCk9uIFR1ZSAxMi9Ob3YvMjAxOSAw Nzo1OTowOSArMDEwMCBJYW4gTGV2eSB3cm90ZToNCj4+IHdoaWxlIF9kbWFyYy5nb3YudWsgcmV0 dXJucyBhIHZhbGlkIHJlY29yZC4gVGhlIGxhdHRlciBpcyBhIE5vbWluZXQsIA0KPj4gYWxyZWFk eSBzb2x2ZWQgcHJvYmxlbSwgQUZBSUNTLj4NCj4gSSBjYW4gc3BlYWsgYXV0aG9yaXRhdGl2ZWx5 IGFib3V0IHRoaXMuIFdoYXQgd2XigJl2ZSBnb3QgaXMgYW4gZXZpbCwgDQo+IGhhY2t5IGtsdWRn ZSB0aGF0IGhhcyBzb21lIHdlaXJkIHNpZGUgZWZmZWN0cyAoc2luY2Ugd2UgcmVzcG9uZCB0byAN Cj4gKmFueSogbm9uIGV4aXN0ZW50IHN1YiBkb21haW4sIG5vdCBqdXN0IERNQVJDIGFuZCBTUEYg cmVsYXRlZCBvbmVzKS4gDQo+IEl04oCZcyBqdXN0IGFib3V0IHBhc3NhYmxlIGFzIGFuIGludGVy aW0sIGJ1dCB3ZSBiZWxpZXZlIHdlIG5lZWQgYSANCj4gYmV0dGVyLCB0YXJnZXRlZCBzb2x1dGlv biBhbG9uZyB0aGUgbGluZXMgb2YgU2NvdHTigJlzIGRyYWZ0Lg0KDQpUaGFuayB5b3UgZm9yIGNo aW1pbmcgaW4uICBMZXQgbWUgcGlucG9pbnQgdGhhdCB0aGUgaGFjayB5b3UgdGFsayBhYm91dCBp cyB0aGUgdXNlIG9mIHdpbGRjYXJkcywgd2hpY2ggU2NvdHQncyBkcmFmdCB0cmllcyB0byBmaXgg d2l0aCB0aGUgbnA9IHRhZy4gIFRoYXQncyBhIHByb3RvY29sIGlzc3VlLg0KDQpBdCBhIFBTTyBs ZXZlbCwgc29tZW9uZSBkZWNpZGVkIHRoYXQgZ292LnVrIGNhbiBwdWJsaXNoIFRYVCByZWNvcmRz IHdoaWNoIG1heSBhZmZlY3QgYWxsIG9mIHRoZSBkb3dud2FyZCB0cmVlIC0tc29sdmVkLiAgVGhl IGJhbmsgUFNPIGNhbm5vdCBkbyB0aGF0LCBhbmQgd2UgKHRoZSBXRykgbG9vayBmb3J3YXJkIHRv IElDQU5OIGFsbG93aW5nIGl0IC0tbm90IHlldCBzb2x2ZWQuICBUaGUgY29tIFBTTyBjYW5ub3Qg ZG8gaXQgZWl0aGVyLCBidXQgSSdkIGd1ZXNzIGxvdHMgb2YgcGVvcGxlIHRydXN0IHRoYXQgSUNB Tk4gd2lsbCBuZXZlciBhbGxvdyBpdC4NCg0KSSBob3BlIEkndmUgbm93IGNsYXJpZmllZCB3aGF0 IEkgbWVhbiBieSAiSUNBTk4gcHJvYmxlbSIuICBTY290dCdzIGRyYWZ0IGNhbm5vdCBzb2x2ZSBp dCwgYWxiZWl0IGl0IG5lYXJseSB0b3VjaGVzIG9uIHRoZSBwb2ludCBhdCB0aGUgZW5kIG9mIHRo ZSBpbnRyby4gIEl0IGlzIG5vdCBhIHByb3RvY29sIHByb2JsZW0uICBJdCBpbnZvbHZlcyBQU08t cmVnaXN0cmFudHMgYWdyZWVtZW50cywgYW5kIElDQU5OIG1hbmFnaW5nIHRoYXQgc3R1ZmYuICBU aGVyZSBpcyBub3QgbXVjaCB3ZSAodGhlIFdHKSBjYW4gZG8sIGV4Y2VwdCBob3BpbmcgdGhhdCBJ Q0FOTiBtYXkgY29uc2lkZXIgcHJvdG9jb2wgZmFjdG9ycyB3aGVuIG1ha2luZyBkZWNpc2lvbnMu ICBBcyBhbiBJbnRlcm5ldCB1c2VyLCBJJ2Qgd2VsY29tZSBkaXZlcnNpdHkgYW1vbmcgVExEcywg YXMgbnVtZXJvdXNuZXNzIHdpdGhvdXQgZGl2ZXJzaXR5IGJlY29tZXMganVzdCBhbm5veWluZy4N Cg0KDQpCZXN0DQpBbGUNCi0tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFp bGluZyBsaXN0DQpkbWFyY0BpZXRmLm9yZw0KaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGZG1hcmMmYW1wO2RhdGE9MDIlN0MwMSU3Q2lhbi5sZXZ5JTQwbmNzYy5n b3YudWslN0NmMjFjZjJmMmFkNWY0MGM2NzQwMjA4ZDc2NzQ4YWU0NCU3QzE0YWE1NzQ0ZWNlMTQ3 NGVhMmQ3MzRmNDZkZGE2NGExJTdDMCU3QzAlN0M2MzcwOTE0MzQxNzU1MjIxNzUmYW1wO3NkYXRh PUVaQ2owUzdncGlvWEMxVVdzSiUyQjh3c1U4RDElMkZQZHRBMkZaR0JuODR2aiUyQlElM0QmYW1w O3Jlc2VydmVkPTANClRoaXMgaW5mb3JtYXRpb24gaXMgZXhlbXB0IHVuZGVyIHRoZSBGcmVlZG9t IG9mIEluZm9ybWF0aW9uIEFjdCAyMDAwIChGT0lBKSBhbmQgbWF5IGJlIGV4ZW1wdCB1bmRlciBv dGhlciBVSyBpbmZvcm1hdGlvbiBsZWdpc2xhdGlvbi4gUmVmZXIgYW55IEZPSUEgcXVlcmllcyB0 byBuY3NjaW5mb2xlZ0BuY3NjLmdvdi51ay4gQWxsIG1hdGVyaWFsIGlzIFVLIENyb3duIENvcHly aWdodCDCqQ0K From nobody Mon Nov 18 07:45:42 2019 Return-Path: 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 6F7B3120982 for ; Mon, 18 Nov 2019 07:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 Zkh7-RBRUYUB for ; Mon, 18 Nov 2019 07:45:34 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 0D245120971 for ; Mon, 18 Nov 2019 07:45:33 -0800 (PST) Authentication-Results: mail.aegee.org/xAIFjTAi029603; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1574091930; i=dkim+MSA-tls@aegee.org; bh=3OJUUyGo1y60TR7Ioy0XLA3710pnWy0FqInc1tvn7d8=; h=Subject:From:To:Date:In-Reply-To:References; b=YZ5d2egjxHLjGrFbKnhEMRJelreuzR/cPpH93I098+8zRNbdQgy5LRJlrI2QU1ZSQ 086DoyrDvlRvkZaPxCllkyF5LSpE1X+BpWvWpTevM6hITUlRpof7/mJ9L+Nv9qfTCI Do/NHxhpRm29/DN46863XTpAiRgbA3PLY7oy2Nfo0Qhq4NKV1BZR5t7EAtzIi9Dki8 OhKQ529F6Vu7WzalZ0wII1xA5xWG9c6aZYzkTufRzeHmI6vi1ln1Tf8zwlBK4CrdE/ 9FyIxEL8J2a0w9w8jjeIG6roB2bMz53iY7iDTW4itY18pwaYegoXw0JlR5nqS/f1V7 hLGeTj8rpmUbky+WJx1UMjpQZEDl6AzEiky7BDT0sbyfnbq2xr1UtV5+ah3UE7lhaX zNQQlktH+Z0f8RDg/E+x5VuS6qoNOaVwDvdFCeph/4XKLv99Ufll80wuE7GMpAMc+N vWo29TTlftFngws2SDn9yIXoBKswxMdkgVQiRTqN3FKUeeT4vRrNLFAAGEZCzBYu01 dvYh0RJUc3YlofJfKDL4vU7w4HD2dmOxHPpO3UajuWyxKzq7SIMGZLshkPnLxKzoYw KWHw5QrtrwCnmPbvu5vozDEHPKFywGIYAUxQ4v8UmlLls622FAxyeuFvOUyXcGCFfz cy9aKpKN+vZYG4R/gvPL4ZMg= Authentication-Results: mail.aegee.org/xAIFjTAi029603; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id xAIFjTAi029603 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 18 Nov 2019 15:45:29 GMT Message-ID: <36e81f7d45fb2c2f90c6b831d1f939e02251d0c4.camel@aegee.org> 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: dmarc Date: Mon, 18 Nov 2019 15:45:28 +0000 In-Reply-To: <20191025174918.E8CAFD66F4D@ary.qy> References: <20191025174918.E8CAFD66F4D@ary.qy> 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 mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] Purpose of aggregate reports / Re:Two new fields in aggregate reports X-BeenThere: dmarc@ietf.org 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: Mon, 18 Nov 2019 15:45:36 -0000 On Fri, 2019-10-25 at 13:49 -0400, John Levine wrote: > In article you write: > > 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. > > As far as I know, the point of DMARC reports is to help domain owners > understand who is sending mail that purports to be from them. In a > large organization it can be remarkably hard to track down every mail > server in every department or every subcontractor that might be sending > real mail with the domain in the From: header. > > The domain owners use the reports to do things like update SPF records > to include all of the sending hosts, update server configs to add DKIM > signatures, or to fix servers that are adding invalid signatures, and > often to shut rogue servers down that shouldn't have been sending mail > in the first place. > An additional purpose of the aggregate reports, currently missing but should be present in the future, is permit the domain owner to migrate from one software for DKIM signing to another software and from one type of signatures to another type of signatures (RSA→ED25519), allowing smooth transition. I mean: I domain owner uses software A for DKIM signing with a=rsa-sha256; when communicating to site B. This works reliably, as demonstrated by the aggregate reports. If the domain owner wants to check if software C also works reliably, when communicating to site B, the domain owner has to use software A and software C at the same time for signing (with differecnt selectors). The aggregate reports shall show, if software C (the other selector) causes any problems, while software A continues to sign the messages. The other use case is when software A continues to sign the messages, but in addition adds a=ed25519 signatures. There must be a way to evaluate, looking in the aggregate reports, if ed25519 between both sites works reliably, while rsa- sha256 does not cause any problems. This was previously rised on this list (Subj: spec nit - which DKIM to report, From: Tomki, on 21st June), I just want to make clear that this belongs to the purpose the aggregate reports should have. Regards Дилян From nobody Mon Nov 18 07:49:48 2019 Return-Path: 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 6821112098F for ; Mon, 18 Nov 2019 07:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 SWOQLqI7sBVk for ; Mon, 18 Nov 2019 07:49:45 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 D071B1200CD for ; Mon, 18 Nov 2019 07:49:44 -0800 (PST) Authentication-Results: mail.aegee.org/xAIFnfZk030400; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1574092182; i=dkim+MSA-tls@aegee.org; bh=sfBCmKe9PX78rL0sc4hcVzwVV005wujkav/drsk7ZkQ=; h=Subject:From:To:Date:In-Reply-To:References; b=rvKi9nDpAC8QWyA7v/GesFWSyWC5tBoCB4idEK63H9nnh4NrKzxuWvX1ArCpzPWFW 5RVNFsCfRbT/rCrnMagVR0v4UE0tZMTMZEVuQc7XZI323NYgCggxyPpveECS8loa3p r7COO5yZKPRW10CC8Tw8pJHG3pHmulWq1l5q8gUh+bKvS9Mdcg9kiUmZBSN5uP1ctY sxrP99Qe3t+Y9NaQbNT8ffW3tB+PuXHm8qc8rPthBeD7ls4Yf8DiDNFjl+N1FP41eg tPeMU9WXImGiYqxm3afo8errMALUaWnG6HnoA07gK7Sl7I3qAkaeWf1qqyY688yrh7 gexc/+bvJJnWyo20ZGxnhFsE+NAEw4DcOAIi79qHQG3PqsNms1VGdYA7ZpVME2//bw +bdXG8nYBLvUwhEFmeXP1y6gwlej0UxyYM5xaX+3r2bXjad7tj9aF1Zj5KDp338LH/ hWVg4WZgLu1S79NQJO9qqVp6VEFyZGQFlWcC4cjnKEvdyybMPIFsjYBTl8Yp8aTu+b cyy+uWRnigxGu5weGy0F0WWAjhUppVWPJN/caH6s4Y4bZ4m3sSv6yJXjH0RymFL8kf PLPcyDp7ombhvVayNZ83hwv9bQYNJHYIlDaPvYjCqIFrLQPW+cXyx88Bm0eSEEiR+c bm58R/aV5vvW2oLCbf3yvs9s= Authentication-Results: mail.aegee.org/xAIFnfZk030400; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id xAIFnfZk030400 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 18 Nov 2019 15:49:42 GMT Message-ID: <0c529630b489d0852fd3fba0e8cdf0b68c6929e2.camel@aegee.org> 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: Seth Blank , IETF DMARC WG Date: Mon, 18 Nov 2019 15:49:41 +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 mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] DMARCbis / Re: Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization X-BeenThere: dmarc@ietf.org 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: Mon, 18 Nov 2019 15:49:46 -0000 Hello, who is going to work on DMARCbis document and is it realistic to finish it with a year? Regards Дилян On Thu, 2019-05-09 at 14:23 -0700, Seth Blank wrote: > With the group officially in Phase III of the DMARC WG charter, our work is now to explicitly review and refine the DMARC specification, with the goal of generating a standards track document. > > The draft-ietf-dmarc-psd experiment is part of this process, as is the conversation about defining proper ARC reporting XML for DMARC reports. > > This email is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which you believe should be officially discussed as part of the DMARCbis process. Please start a separate thread for each item you have. I'll make sure all are properly in the issue tracker and get addressed. > > Please send in your items no later than *Friday, May 24th*. After this point, we'll be focusing on progressing the DMARCbis process, not gathering new issues. > > Below are a list of nits already in the datatracker. I'll be kicking off threads for several other issues I'm aware of shortly. > > Thanks everyone! > > Seth, as Secretary > > Active issues for DMARCbis in the data tracker: > - SPF 4408 vs 7208: https://trac.ietf.org/trac/dmarc/ticket/1 > - Flow of operations text: https://trac.ietf.org/trac/dmarc/ticket/2 > - Two tiny nits in 6.6.2 and 6.6.3: https://trac.ietf.org/trac/dmarc/ticket/2 > - Definition of "fo" parameter: https://trac.ietf.org/trac/dmarc/ticket/4 > - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5 > - Fuzzy normative language around filenames: https://trac.ietf.org/trac/dmarc/ticket/6 > - ABNF for dmarc-record is slightly wrong: https://trac.ietf.org/trac/dmarc/ticket/7 > - Perverse incentives to use p!=none & pct=0: https://trac.ietf.org/trac/dmarc/ticket/22 > - objection to maintaining registry for all participating public suffixes: https://trac.ietf.org/trac/dmarc/ticket/24 > - Link to "URI" reference broken in several sections: https://trac.ietf.org/trac/dmarc/ticket/25 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Nov 30 04:40:53 2019 Return-Path: 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 07DBA1200A3 for ; Sat, 30 Nov 2019 04:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it 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 FaF8bN_jBhEC for ; Sat, 30 Nov 2019 04:40:49 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECC0120091 for ; Sat, 30 Nov 2019 04:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1575117646; bh=gXQ018FLEO5bIeOdBl2bgKSSTS7cW3euUNNheqRLZL4=; l=1546; h=To:References:Cc:From:Date:In-Reply-To; b=AtQ175dwWXBoXjfwCzvaEfaJz095DiLIPygjdTG2T34BAetc/Ppv8ZosD9jWzw3Qz Pu1KsL8K6V1keJhQwx91ffmwtohOfe9AIEqJVMLS8MDp74KD8Ev8WxXfePMt8IhKlO AWp1ISnWS4c6L18FwJNhoEYdR/WXe4hVb86MhNLXXvU6o5Os+3OVLy1tMAYH+ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC07D.000000005DE2634E.00007AED; Sat, 30 Nov 2019 13:40:46 +0100 To: dmarc-ietf References: <458060E1B9558124988A46B7@PSB> <2E5DE6BD20354824E99E564F@PSB> <84F1134E-5031-46BB-8C78-9E76FF971100@episteme.net> Cc: John C Klensin From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <79130263-06d5-6a63-e6c6-81b67695eb48@tana.it> Date: Sat, 30 Nov 2019 13:40:46 +0100 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=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] From: rewriting, was Email standard revision X-BeenThere: dmarc@ietf.org 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: Sat, 30 Nov 2019 12:40:51 -0000 Let me quote this from the ietf-smtp mailing list: On Sat 30/Nov/2019 00:12:53 +0100 John C Klensin wrote: > --On Friday, 29 November, 2019 11:16 -0600 Pete Resnick wrote: > [...] >> Even the "From: rewriting" issue is >> a gatewaying issue, not a message format issue per se. > > That is less clear. It fits into the gray area that has existed > for years about just exactly what a mailing list exploder / > redistribution system really is. We've traditionally threaded > that needle by saying that, if the message is simply > redistributed, without messing with content (or headers other > than trace ones), then it is an SMTP matter, and that is what > 5321 talks about. If more drastic changes are needed, the story > we have told is that the mailing list mechanism is acting as the > agent for the mailing list manager and really more like a > specialized MUA. I don't need to remind you about this, but > that it the main reason 5322 specifies "Resent-" header fields > and 5321 at least implicitly forbids true, MTA-level exploder > from messaging with them. So, as I say, not clear. And, fwiw, > an argument that anything rewriting a "From:" field should be > identifying itself in Resent- header fields. I, and probably many others, agree with that, as it describes the current state of affairs smoothly. Shouldn't we translate it into a WG RFC? A "Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Mailing Lists" thing, similar to rfc6377, possibly shorter. Best Ale -- From nobody Sat Nov 30 07:37:12 2019 Return-Path: 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 C00101201DE for ; Sat, 30 Nov 2019 07:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 B7EYUxK3PYy6 for ; Sat, 30 Nov 2019 07:37:08 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB21120119 for ; Sat, 30 Nov 2019 07:37:08 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id l136so12940588oig.1 for ; Sat, 30 Nov 2019 07:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=tPzPBGlIbAi28Bpi0YsyaPlHywrqNwsPp9SeJcoG4XA=; b=ALU+GpertBuFcqczOeYI3tTrhGk8aUIZzPt4NMxFh9ytEZbTdH7wiE69VVsYMej3re +zUOYOX2zj681n6eoC0Dl6Z5giDgVdlGrmxWNbvJmdlitvpLTVSwLehQFU/+PN2IyGED NODZx7O45+dM5Ww0jOTr9k8W68cS4nwUsNNgtRqLQ/TEagJd2eVNhkKIN9UorN9dmazm DOyCtyMQr4eUBsqbcwKXmDIsmjk8VXUVazwXkXgCzWVXzySeSgCDMvBf5oVzaUbNl3pX CNDw0GvGKL1m5O9B0tCo0h2w6K0/KwhBWh9AjXnkWj1ztlXQ7KGLfjuMHlyt4QhctLYO DhiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=tPzPBGlIbAi28Bpi0YsyaPlHywrqNwsPp9SeJcoG4XA=; b=HO3hXTGqOguvw/iGNcXRY/j9GhEmJVyt/7DZRctYHfHa7fcEn5pR4RpADw2RsT1Vot nB8v9K7Q406hJbrAplqdASMnAt/yg26UHkM10v0kUn6jdD7dgXZz6cC4tX5T2xjxUaID +DK4/3zuoWsL6LCSWTcCgAUENNlFQf8tQ7raIiqK5tGBDjfQ4gk9hK6jYRs6/Zh0JeXj /iWOsGQPrmE+kKOMK4eJlLRDgKSUsYj6SGSxn2tkxr7SQHmb849jbuJiEWS8efc62Vnt XcPAqrGyQyo64MI8ctM3MJTgo4Ye0O5FH+vCXWR9WfuGI/hQwymzY5c/j1IpF8JHz0ZG I8KQ== X-Gm-Message-State: APjAAAW5Ky4LcAr/f/Kbc+R9h5ju2aC7pSMm4GramTWKvGBsq0AMdJ0y CvguGnXJg4Ig6UtukSf3HVM= X-Google-Smtp-Source: APXvYqzwPgVQVi9I4nhRH97JZxDEhAv/KyiUA8Wg1nu7PQv96DJiIOJzg6JyO0FJ727GiBQIpuDrKA== X-Received: by 2002:aca:48cf:: with SMTP id v198mr5273532oia.35.1575128227729; Sat, 30 Nov 2019 07:37:07 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:b81c:3778:bc3:43e? ([2600:1700:a3a0:4c80:b81c:3778:bc3:43e]) by smtp.gmail.com with ESMTPSA id v26sm8536695oic.5.2019.11.30.07.37.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Nov 2019 07:37:06 -0800 (PST) To: Alessandro Vesely , dmarc-ietf Cc: John C Klensin References: <458060E1B9558124988A46B7@PSB> <2E5DE6BD20354824E99E564F@PSB> <84F1134E-5031-46BB-8C78-9E76FF971100@episteme.net> <79130263-06d5-6a63-e6c6-81b67695eb48@tana.it> From: Dave Crocker Message-ID: Date: Sat, 30 Nov 2019 07:37:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <79130263-06d5-6a63-e6c6-81b67695eb48@tana.it> Content-Type: multipart/alternative; boundary="------------476176BED4137D3309AAD8EE" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] From: rewriting, was Email standard revision X-BeenThere: dmarc@ietf.org 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: Sat, 30 Nov 2019 15:37:11 -0000 This is a multi-part message in MIME format. --------------476176BED4137D3309AAD8EE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/30/2019 4:40 AM, Alessandro Vesely wrote: > Let me quote this from the ietf-smtp mailing list: > > On Sat 30/Nov/2019 00:12:53 +0100 John C Klensin wrote: >> --On Friday, 29 November, 2019 11:16 -0600 Pete Resnick wrote: >> [...] >>> Even the "From: rewriting" issue is >>> a gatewaying issue, not a message format issue per se. >>> >>> That is less clear. It fits into the gray area that has existed >>> for years about just exactly what a mailing list exploder / >>> redistribution system really is. This view is reasonable only if one re-defines accepted terminology and ignores some basic technical facts. A user specifies a recipient address. The message is posted and then delivered to that address. That simple process describes basic email handling, and has been the accepted view for roughly 40 years. And it describes the /first/ leg of a message sent /through/ a mailing list. For the second leg, a bot at that address /re-/posts the message.  In simple, formal email technical terms, this is an entirely new email transaction. It isn't 'gatewaying' per se, since that term applies to transit between heterogeneous systems, but it /is/ a higher-level process. If only we had a document that discussed all this coherently, defined basic terminology, and had undergone IETF review and approval.  If only we had RFC 5598... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------476176BED4137D3309AAD8EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/30/2019 4:40 AM, Alessandro Vesely wrote:
Let me quote this from the ietf-smtp mailing list:

On Sat 30/Nov/2019 00:12:53 +0100 John C Klensin wrote:

--On Friday, 29 November, 2019 11:16 -0600 Pete Resnick wrote:
[...] 

Even the "From: rewriting" issue is
a gatewaying issue, not a message format issue per se.

That is less clear.  It fits into the gray area that has existed
for years about just exactly what a mailing list exploder /
redistribution system really is.  


This view is reasonable only if one re-defines accepted terminology and ignores some basic technical facts.
A user specifies a recipient address. The message is posted and then delivered to that address. 

That simple process describes basic email handling, and has been the accepted view for roughly 40 years.

And it describes the /first/ leg of a message sent /through/ a mailing list.

For the second leg, a bot at that address /re-/posts the message.  In simple, formal email technical terms, this is an entirely new email transaction. 

It isn't 'gatewaying' per se, since that term applies to transit between heterogeneous systems, but it /is/ a higher-level process.

If only we had a document that discussed all this coherently, defined basic terminology, and had undergone IETF review and approval.  If only we had RFC 5598...


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------476176BED4137D3309AAD8EE--