From nobody Sun Mar 1 04:46:59 2020 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 07D0E3A0E6E for ; Sun, 1 Mar 2020 04:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: 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 SYsUik983G-8 for ; Sun, 1 Mar 2020 04:46:56 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 206EE3A0E37 for ; Sun, 1 Mar 2020 04:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1583066811; bh=Jb6T+WZmdGyRaSdnIBux591Re2tcFpKfNCgeWWI070E=; l=576; h=To:References:From:Date:In-Reply-To; b=BaVSQHdD3h62IxvUpRxtRjCRWIzPoeMXCOt8vl2lXm5Yem7NJAfso3SdTnVFVvQA6 G9hKOOjes7jmQyE+EepKgftjHfCAlBWOrj4ziCku9JHAvgROcLbpjKV1XZX3eeg0wU 9dHfTWVupF8Wz4AR87kSxwpsNirjYnhlmkUbeS1lkCxoZ1E8zkGaaB8hZUSYz 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005E5BAEBB.0000542A; Sun, 01 Mar 2020 13:46:51 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <9a8c0ba6-6a0c-070d-4c44-9eb00fb68e26@tana.it> Date: Sun, 1 Mar 2020 13:46:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 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] A tweak to 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: Sun, 01 Mar 2020 12:46:58 -0000 On Sat 29/Feb/2020 20:19:27 +0100 Murray S. Kucherawy wrote: > I'm ambivalent at this stage about whether this makes it into the PSD document, > but please someone do add it to the queue for DMARCbis. Done: https://trac.ietf.org/trac/dmarc/ticket/34#ticket That definition makes a neat distinction between "Public Suffix" and "Public Suffix List". From there, I think it will be easier to give a semantic definition of "Organizational Domain" which leads to a good enough, although possibly not optimal, practical tool for its determination. Best Ale -- From nobody Thu Mar 5 07:34:52 2020 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 286DF3A1676 for ; Thu, 5 Mar 2020 07:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=protonmail.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 bY9f46hIGcEl for ; Thu, 5 Mar 2020 07:34:45 -0800 (PST) Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) (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 618043A1675 for ; Thu, 5 Mar 2020 07:34:45 -0800 (PST) Date: Thu, 05 Mar 2020 15:34:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1583422481; bh=1mOSn8WWUawfj47UaQLQ24y6+I36nYStdu7tdcSau6Y=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=OpZzr33SdA9jWN9ixQVcyGsGi1AYFZYmDog7i32QHjCXotPIilJCvFjObeu8oxPd1 RpuBOgZXzJyhfeVU58Jq+bd70sPeJhJK0PLf99M5SLo1frmV/8mGGBZ/JpCDWZF2G3 uhzV81Ewmr85N8o4ZlLc+0o4NIvPrdQhYiBwNolU= To: Alessandro Vesely From: Jane Moneypenny Cc: "dmarc@ietf.org" Reply-To: Jane Moneypenny Message-ID: <5W7o8wEDzKkO_XN-2FP_5cR7XtYYQrQThd7gAIV7FDxZmkVkpfIH4-kPrb-s4iV-TnHS-M1F7J80g_obImMUM3kYe4Vhw6fF1c8uIs9ZjsM=@protonmail.com> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> Feedback-ID: maG8rBvbVesMvSttssIWvHvk4FVyIn95_Qx9mK3VOL2K8_0Gp4G9wiVKu5rDHO6CjG4Ix8q6os17SKjYvK8tHA==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_f5a998543402de02c8110b0f2f0f0777" Archived-At: Subject: Re: [dmarc-ietf] Comment on DMARCbis, was 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: Thu, 05 Mar 2020 15:34:51 -0000 This is a multi-part message in MIME format. --b1_f5a998543402de02c8110b0f2f0f0777 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 eW91IGhhdmUgMmlkLCBidXQgeW91IHBheSBvbmx5IGZvciAxIGlkLiBJIGRlY3J5cHQgMUNBN0RG QkYKClByZXNzICJEZWNyeXB0IiwgcGFzdGUgdGhlIGtleSBpbnRvIHRoZSAiRGVjcnlwdG9pbiBr ZXkiIHdpbmRvdywgdGhlbgpjbGljayB0aGUgIkRlY3J5cHQiIGJ1dHRvbgoKc3hyekZ3dVB2OUVN Vi82YXhkS0lXbHZNdlpHamVoQnhjS3lmR0FHYVJkeUp5VmQ3aUdSSCttQ05VL25zNlpvQWpqK2Fn b0dFTkNnTHg2VDd6Z3p6RzdhTTBDa0pmYjJhSWt2OFYxbTFQTEJzTGl0M3RNbXovSFFHK211NGxP emYwbElBenY5aFpkZ2ZJVFNtODhuSmxkcDNkZk00OFNCZUVXUmVWK3V4L2o4ODM5L2ZLU2YzM1k3 Rjk2VHMrVHlXOFdJMStBMUd1TFFOMjVVTU0yakFvQWJwRENSRWlCc1NETXVwNlRGeGtUSjBSSlZJ QjV3SE1TSkMzMWpXQ3ZhNWM3Rno5MHk4WmRYYUZoVXJYY1ppWkoxMUZzb3JmVnd4aS9ia3djYitH RVVSRmZkMTdobDRhZWQ3YmVHVHphWmtraDVYRzdMOFV6ZEZpRDZiRkNYZlRVOEd0OElYcjdvb3Br ZTA3RDFzajJBT2NIdlVRb3QyNERDRnJvWjZaQU45VHZQTHNSMldxK1lzc1YyTUdxRFplV2ZSRUtG eW5IamZEZHVWREROb3dLQUc2UXdrUklnYkVoeHI0WTBxMWxxaGVSSFQwbnRQalRwcGZFaWhNTGNv OTU4VmlERmF2YmVpL1R3aUNDanRyN3BlUHpuaVZmRmpuN3hnbDNWd2NFbXNHakZlNCtvNFlvQWVt b0Z6eG13UDczbnRpdVlnRnJ1TzlMNzFSUHJ0cVR1a3dZNVB0RStaQ0RLY0xKRWFEb2I2TVdWU0dH Y09sZlFJbFRZQUdCYmJ4TytQNzdLL2pEc0NVb1J5eTV0THczY0VqdGpBUXBXbkJBM2JsUXd6YU1D Z0J1a01KRVNJR3hJdHdMUER6Q3RtN2ltOE05Ti91Y2JXK0FuYkM4VXJDYVZLZndFVmxsUFc5NGVa RGowTjRGcjVTNzJyVTZVRElWRXNxcnAwL04rOGpMdlJLN1QyZFJVb2dWV2JhK0RXenBBYnNaZm5Y VGJLc3BrSEh4SCtDMnB3QzdMMFZFOEE1OGhzNmM1Mm1QUDlFSml1RnVud25XR29BRW5FVDJEaWJX cTRYVDB2QkFSSFg1cHVjV2doeCtoQTQ3V3JERlpjTis4TjI1VU1NMmpBb0FicERDUkVpQnNTTTE3 ZkpUUkYzN2hVVFVqU0hNV1hRdHBRUnRMUmR0VE0yRGtvZDA0dWVqQXZnSFhiNWJMd3VadldlYjFE M1l0blVQR3FEamhGODJrTXRwbEQ5VEZYMElydmNBUUMrRmZsYnd1UGk1VGZ3bmNUNkdpN3hSQUhH Y1dlcUsvSmZ5SEk4bkpwSS9VaUdRenlxK1BJSllLL2tBRTd6UTJJK1FUcG1RVTNKWDBBMlFnZDg5 eVFHbU9SZStUclFqY3Zud1BxRGR1VkRETm93S0FHNlF3a1JJZ2JFamU0ZzdWQW5aUUowZjZHTC9F K1pOMXVnSjRneXRBUjBYQWxNTDRGencrb0xDc29DYTBNaUMvb1RBaDl4eUk2TTN3allzcGQ3UFJj dEUya3EySTVaUWRidGtYWFp0QUkzb2tPNUZHZFd0MUpMTnRwL1JEUVY4eW03MVZob2IwYTJjRXpP ZmpLZUZodDZ3SitLZ0RHTG5iK0lPYkhmQ0NJTXFxalF2dkNVcVFPUUZpT1NBS2wrcmZTNE85MDZF V1hrdzNibFF3emFNQ2dCdWtNSkVTSUd4STM0Wi9RQnlaVUYrVzhHSElnWUE2ZlVING93REdsMjBr S1AwSlYxdUsreDJ6aXVOK3hLcUlFQzh0S2N5SXpJdzhsYWxBdFl4UzJKc2hkR3lQYkx0RTNsdThp eHhLUTFiSVdCeFVlZDJJVWlKci9WendHeFZFUWkyQ1ZqWGQ2cjlhR0hzdGRVVHZSTEJPMFV6bW1j S240SXB1L1JWL0RxeUFqRVkrVVlUNVdVbE9pYjN6OUJkSEN6ZWl3RWN3Q3BJUU4yNVVNTTJqQW9B YnBEQ1JFaUJzU1FkU3RjMGNpSG54bzVrT0FFQU52TW1LUFZWZkY3YXFGSGh1TlZHUWtQNXNKazVu NWw4WDJxU2ZtSDR6Z3J3TkZSSXFWSlhabFMyL2w4QzQ0THdnR1FxcDNVanlvZ3E3RnBLaUFOK3lQ U2F5bVgwQ0xHeGZOQUNzK3QxZXpPcW5lQUNsWGVlbkNMZ1crQk9OR29UUlg2N3ZkTjRvaDlsZ21X aXZZVkNqcUJyMVZnMlNTcHMvczdKblNSL3lWWlJmMURkdVZERE5vd0tBRzZRd2tSSWdiRWtQRmg2 SmRFaFBSZ1RJMGxncUhmRDFSemNTRmQ4ZFdINlFLVVAraDhuWVpQVUlIVkJWNkQvNEFTNndic09E WFdPeENldTlFZUxpOUd3VExsVXB1S1VIRnIyUytDeGRsem9XVTFIR20zYWdNMDNFZzQ0blROY0RC czh5SmFlVnVMTC9PblJRVVFEV2xub1BjdmozaFNrTXppY3lOeFNMYjdTeEdRMnZmdWdsSVRUMWxU S1oyRHVJN1JVdjNoVExtQ0EzYmxRd3phTUNnQnVrTUpFU0lHeEpFVVl5anBkRERnTVZpT2ErbHBx WlEvejRKOXNKc2x5NnJUcFFZSENoUXQxNGg5b01nTDlMN2FRY0YyMkJEUFlGNld3MVc1S3dkSHdo cXE2SmZua25zQlVGVEc1VHBieUNtNWZIbDhBSjAzdXVKek5wdmJwSS9jZmVmbnRvZjNkVDFlRk9K Q2ZwOEJDdzd6UHhsWUF2RU9FNXM5UGswcHBTdmVTY3JOWmlpcnFubVJiaG1yOW9zK3BwanhPV05y MWtOMjVVTU0yakFvQWJwRENSRWlCc1NVRnZIZkE1ZUdVSjFOSkZCK3p0VFpSUzEzeUdPZ3YxZ2xP d3JXM25GL2RCaXZycTUyN0xYVVdWLzFINExvblUyMTdPeFZKOXpUSWxKMUdRakNlL3IyampxYlUr T2g4VFNxV2prdDByTXhWNzFtQmoyZmc1M0kzeEpxNjlzZ0R0UjFlaUFhMDNFS2VzazVuYzBFeFgz dHBHRzJZZW4xZnBpRjB2Q0VBd25ISTczYXoyR1ZmUURYTHhKSGhRMWFpNjVEZHVWREROb3dLQUc2 UXdrUklnYkVsaFBtZWpUMno1c01vUy9qcjZUdDlaK0JlcmV6WmdSaHBPU0FOM1NwaFdYbXcrWmFP YTBIVUFsMUZNK2QxS2Zka2NBcGVkYVF0VWFlMFFUNC80Zy83RlJBRzludUFCYUUwczQ0SlZNMVV6 c3hhdlZGaytXejZaNElJdEUwV3Q0dzZrS2NYRkN2K0pNcmlWN1djSEZpZGg5elNZSkJjNmlqTEdx aG10QlU2aEsrSGFSVjhIdXVlV1BnZU5hR1VUQktBM2JsUXd6YU1DZ0J1a01KRVNJR3hKY3JlVEdl WUJETVc5dHNWbzl3VU9NUW9sNGM4RU14OEFXanNmbUR2MG51eFJXTzdIUWVPRXlsdmY2QzV1cGVy anRoT1pGVzJQVTdWa0ZPQ1VKMnU4WVkvY0thVWlxOXVMN2huRFdLenhjMDd2MlFSTFk0L01aRzhM NUpiOEMvQXhicE9FcXFUYktTc2lKeUQ3S3loOTMxTmtWTFhNeVlBVVVtaVdtRVd3dVRCYmtVYkYw c25mS3Ntcjg3bHRRM3dFTjI1VU1NMmpBb0FicERDUkVpQnNTYnFFQVFwTjdHRW1rRVgvVXI3Q1Rm M0lGNXpNalZsYVJLNjRIOXlxZWJQK3hIOVBFRWNra2poVjY1c3dKMHpGeVJ5ZmtCMHFRVllabGNG ZW85dXRPZEV1U21FZjZDbWlreWhabE9HdWs5MkdzTnA0ZDZ0MVc1ckdlVk5MVm56cEtKeVFOWHlG YTdoVHdqS3Q3bmpJeWY0eTM0V1B6RTR3YmtGVE05enp5UjNSMmpicTVmcGhBSUlUSVhaZEE2Mk5o RGR1VkRETm93S0FHNlF3a1JJZ2JFbkorck9veHhHd0FneU5Kc2diOTVCOTlLOWQ0UXlzb2xDZ3ZP TDNqb1I0bnRNME9HYStWeEw2enVuQVN4OUN0RlQ3a0VROFZ2YmtTRzVESmdtTzF6SStKVGFEbHBm MGxqSUQ4UTdZTS8ySkxnTDFQMy84d0pZeitmVmJFeHVlMmtJRHh6YzFJVG5kWmU0Mk9CWHAvb1FT SHEyUDdyRXJqbHpKUHUzbHc2MVhDcjJzWUkyTmZ4NXdNSkU5TXkzOUhNdzNibFF3emFNQ2dCdWtN SkVTSUd4Snl1QTFRRWd1YzBHd25PRHVud2kyNjZIVmJJaG9kcGJ1cGVTZ3dra0trNUZ3RTdyUTY2 L3lPTldYUlB4UDcrNDY1YzRUZEllWHA3QSt1ZEpuOEk0WlFtTWdTblFtdU9SbXg5NTFBTXhRS2FZ S3pnb0o4RS9Oam4zUnUzWUVTRldGRlVFeTNMN3JtdVF5ZTFWdUc0N2k2SDhhK1dlYkJ1TDN2UkpB bzA2MTJMSHoyYllmU2NCTzhGSEpRZXZHa2pEY04yNVVNTTJqQW9BYnBEQ1JFaUJzU2RNWGFiUjYr bUtXV3VVMFRzT0RuazRuaFBjb0l2Nzh2YlkreFNNeEw2M1krdU5vN1ZWdVo0WVNwc2hPcUhQYW8w UEt2WHNoU3hna2s0KzBXS3VOU1NxYW5IaWwyLzNzOW93UU5oL3pDL1poRFZPVWNGUmRJc3U3b1dY UGhTaVZRWFgvK0hHeTBqYWQ3ZVB5blNoZlkvRXhWRmFCUFh6QmRDbHJBZVVQRjBZWE5mZUZwUkt6 T0x1Y1drZ0puSkEwSURkdVZERE5vd0tBRzZRd2tSSWdiRW5sMnRVSDladkxYbXkzdGNDZzFicXpk U3VLUnZSQ3NCTXRvV3U3UlcwSFlXd25zRWpqMU1IbkpjVnJ2OXZhR0hJalp2OGxoMStFaVM4bE16 RTRwNE5OcEFJaXRFUmxUZVZLaXpCSmd5VHNEa0NQSFBYQml0b2Fhc25wcnd5aTh1VzNjczN2OGt5 c1BtZjVDMDdXbjBwYzdXNnNMRW9FUjN5eGhaQjJqTlM5Ui9MNGlUaE9yVy9VM0JFYzB5SkxkdWcz YmxRd3phTUNnQnVrTUpFU0lHeEtFQW5zR3R5YkVyeFdvT1ppNUVqa2RsOTBDd2dOZC9FMGYwYndY Vm1qdXBxSmpwRWV4Q3ZZTXBZYmlERThnbi9PaDQybUg1VE9IeGlmV1MrRG4wT2JNZVR0KzR1cXVW eFp6MjFwdnZldmdPbVpCVWJmM3lPZ2VVb3hsc29lTlA2b3lHZ2hMQm9FMjQ2T05aSUYyUXp3c1Jl VFROMlRuYkQ2ajNaU095dlJ4ZjErWDRlSG5ZVHhKNVhVY1RHRDVpbUVOMjVVTU0yakFvQWJwRENS RWlCc1NpbHYxWFYrWXVEb2Q5QzFBM0lzdGRxR1JqNzVKR05xQUUrNHVwK0dyNDZsQnBSYjF4RDRQ alJOeXJYU1NSR3RzRzJydEM1WXNjV2d3UW1MUVhaMHRQWWxkRDVjTjY2NXZMSlN3dS8wZFRCazJi UXJvYXpVWk1UZmZjRy9CNFpyUmN4SEIxNFFDdVRydmlEeVh0d3hvS042M0hxWjZSSHR3UU5naUwx bGZBUWNEOUVlSVIrdnVUeWs3MmxIUWtDeHFEZHVWREROb3dLQUc2UXdrUklnYkVvc2lBQmhKTXkv K2VNOUVrTEhjaEpCK25JMFYxUkFmT0JBNnZYUTFCYm1aWk5ORDQyRHJTZ2htMDdNdlJBT1hMbGwy cjhYSVpVRGxneWRmVFVDVjZDR1ZBZmJTNGVrbU9pVVVJcmhsbXJ4OUd0NTljWEFydEthSWxCOC9Z VnVyMC9seUdib3o2NFJORXMxMUZSRlhhZWRVbWZWb2QrUUtrclgwVEdkQkNoTjR3SDE3N2RoMDB1 M21yV1lKTEpQMkpnM2JsUXd6YU1DZ0J1a01KRVNJR3hLUVVrNWVzbURXK2xaRUEvSGtBOEJRMEhw MzdSai8ySjJnbENaUDgrVUxyUVQxSTdvTjBBU0t2ZWg5RjhvNnZsR3EwQjZqYkVUa2UwditEczkz elJHVmF3NEN4WTMya1pxcTFFcUV2SWVGL1NBZllBQVdrREQxNmJSemJlYUlOcjBMbmUyS3NNUEdV Qld0RGI3aFpSVzZkNmVYc1RDWmcwUG9PbXJqQWdlUW5kTzd2Q3RwVStsZGdoT1JZYVJHeDVJTjI1 VU1NMmpBb0FicERDUkVpQnNTa0cwS09NMFFTcndwMkhMb0F5cDc3c2FGbDR0Tm03MzF4UjEyRVI1 d3BXRSsxTkZJaDhpeEZoRDNvSW9ZVUljR0JSZjNIald0UGpySm9ic1hsMXM1RCs3SUNqY1lUcFAx dllFQ2FtV0dWLzZ5WlpwTUI5U0o4T0dWZ21MZkNNVXIyaGsycEdUaFloMzFaS3Q0QUFPbGFpVnY3 SStFSEUvRTlPOERCVnEzN1I5U3VwWFo5NzlYeStQTXJuQ1c1dGVPRGR1VkRETm93S0FHNlF3a1JJ Z2JFcWN3TTFZU1dUYVFQYTZYVndGRy9ZdHdyMVY5UDJqU014elpzRERzclMvS2N1MVVOTXZhZm9H SFpVN2FCUm1wS29Vb3hqditKYjIzK1Rld2UyWDhiay82N1A3UmRHSE5mdU13TUphell2ekExM1Vu U3ViNThkRW9IMktGWFo2UlZrQ2xsNlBmUUYrbWJJMTU5cVhvSFRlSlA4N2dTekhpTUNoR2dDejZV Z2s2elk4dm1wcldMUzhCMWk3OTkrd00vUTNibFF3emFNQ2dCdWtNSkVTSUd4ST0KClNlbnQgZnJv bSBQcm90b25NYWlsIE1vYmlsZQoKT24gVGh1LCBGZWIgMTMsIDIwMjAgYXQgMTE6MjUsIEphbmUg TW9uZXlwZW5ueSA8amFuZS5tb25leXBlbm55PTQwcHJvdG9ubWFpbC5jb21AZG1hcmMuaWV0Zi5v cmc+IHdyb3RlOgoKPj4gRm9yIGEgc2Vjb25kIGlzc3VlLCBjb25zaWRlciB3aGV0aGVyIHJlcG9y dCBnZW5lcmF0b3JzIHNob3VsZCB0cmFjayBwb2xpY3kKPj4gY2hhbmdlcyBkdXJpbmcgdGhlIGRh eSBhbmQsIGluIGNhc2UsIHNlbmQgbXVsdGlwbGUgcmVwb3J0cyB3aXRoIGRpZmZlcmVudAo+PiBQ b2xpY3lQdWJsaXNoZWQuIE90aGVyd2lzZSwgUG9saWN5UHVibGlzaGVkIHdvdWxkIGJlIHZhbGlk IGZvciBvbmx5IGEgcGFydCBvZgo+PiB0aGUgcmVwb3J0ZWQgcm93cywgcHJlc3VtYWJseSB0aGUg bGFzdC4gSXMgdGhhdCBhY2NlcHRhYmxlPwo+Pgo+Cj4gU2hhbGwgdGhlICJwb2xpY3kgdHJhY2tp bmciIG1lY2hhbmlzbSB0YWtlIGludG8gY29uc2lkZXJhdGlvbjotCj4gLSBUVEwsCj4gLSBETlMg Y2FjaGUgaXNzdWVzPwo+Cj4gU2VudCB3aXRoIFByb3Rvbk1haWwgU2VjdXJlIEVtYWlsLgo+Cj4g 4oCQ4oCQ4oCQ4oCQ4oCQ4oCQ4oCQIE9yaWdpbmFsIE1lc3NhZ2Ug4oCQ4oCQ4oCQ4oCQ4oCQ4oCQ 4oCQCj4gT24gVGh1cnNkYXksIEZlYnJ1YXJ5IDYsIDIwMjAgNzo0NCBQTSwgQWxlc3NhbmRybyBW ZXNlbHkgPHZlc2VseUB0YW5hLml0PiB3cm90ZToKPgo+PiBPbiBUdWUgMDQvRmViLzIwMjAgMjI6 MjY6MzAgKzAxMDAgTXVycmF5IFMuIEt1Y2hlcmF3eSB3cm90ZToKPj4KPj4gPiBPbiBUdWUsIEZl YiA0LCAyMDIwIGF0IDE6MjAgUE0gU2NvdHQgS2l0dGVybWFuIHNrbGlzdEBraXR0ZXJtYW4uY29t IHdyb3RlOgo+PiA+Cj4+ID4gPiBJIGFncmVlIG9uIERNQVJDYmlzLiBJIGRvbid0IHRoaW5rIGFk dmFuY2luZyB0aGlzIGRyYWZ0IGhhcyBhIHNpZ25pZmljYW50Cj4+ID4gPiBlZmZlY3Qgb24gdGhh dC4gV29yc3QgY2FzZSwgaWYgRE1BUkNiaXMgaXMgZG9uZSBiZWZvcmUgd2UgY2FuIHJlYWNoIGFu eQo+PiA+ID4gY29uY2x1c2lvbnMgYWJvdXQgUFNEIERNQVJDLCB0aGVuIHdlIHB1Ymxpc2ggRE1B UkNiaXMgd2l0aG91dCBQU0QgRE1BUkMgaW4KPj4gPiA+IGl0Lgo+Pgo+PiArMSwgYWxiZWl0IEkg ZG9uJ3QgdGhpbmsgRE1BUkNiaXMgYXJyaXZlcyBzbyBxdWlja2x5Cj4+Cj4+ID4gSSB0aGluayB3 ZSd2ZSBhbHdheXMgYmVlbiBhc3N1bWluZyB0aGF0IFBTRCBETUFSQyB3b3VsZCBiZSBpbnB1dCB0 bwo+PiA+IERNQVJDYmlzLCBzbyB3ZSB3ZXJlIHBsYW5uaW5nIHRvIHN0YXJ0IHRoZSBsYXR0ZXIg YnV0IG5vdCBjbG9zZSBpdCB1bnRpbAo+PiA+IHRoZSBmb3JtZXIgd2FzIGNvbXBsZXRlZC4gVGhp cyBpcyB0aGUgZmlyc3QgdGltZSBJJ3ZlIHNlZW4gYSBkaWZmZXJlbnQKPj4gPiBzdWdnZXN0aW9u Lgo+PiA+IEknZCBsb3ZlIHRvIGhlYXIgbW9yZSBvcGluaW9ucyBhYm91dCBvcmRlcmluZyBvZiB0 aGUgd29yayBoZXJlLiBUaGlzIHNlZW1zCj4+ID4gbGlrZSBhbiBpZGVhbCB0aW1lIHRvIHJldmll dyBhbmQgdXBkYXRlIG91ciBtaWxlc3RvbmVzLgo+Pgo+PiBUaGVyZSBhcmUgcXVpdGUgc29tZSBp c3N1ZXMgYWJvdXQgRE1BUkMuIExldCBtZSBtZW50aW9uIGFnZ3JlZ2F0ZSByZXBvcnQKPj4gZm9y bWF0IGZpcnN0LCBhcyB0aGlzIGJyaW5ncyBvdXQgYSB0aGlyZCB0aGluZyB3aGljaCBjYW4gYmUg ZG9uZSBpbiBwYXJhbGxlbCwKPj4gbmFtZWx5IHRvIHB1Ymxpc2ggaHR0cDovL2RtYXJjLm9yZy9k bWFyYy14bWwvMC4yLgo+Pgo+PiBWYXJpb3VzIHR3ZWFrcyBoYXZlIGJlZW4gcHJvcG9zZWQsIEkg dGhpbmsgdGhleSdyZSB3ZWxsIHN1bW1hcml6ZWQgaW4KPj4gaHR0cDovL2JpdC5seS9kbWFyYy1y cHQtc2NoZW1hCj4+Cj4+IEZvciBhIHNlY29uZCBpc3N1ZSwgY29uc2lkZXIgd2hldGhlciByZXBv cnQgZ2VuZXJhdG9ycyBzaG91bGQgdHJhY2sgcG9saWN5Cj4+IGNoYW5nZXMgZHVyaW5nIHRoZSBk YXkgYW5kLCBpbiBjYXNlLCBzZW5kIG11bHRpcGxlIHJlcG9ydHMgd2l0aCBkaWZmZXJlbnQKPj4g UG9saWN5UHVibGlzaGVkLiBPdGhlcndpc2UsIFBvbGljeVB1Ymxpc2hlZCB3b3VsZCBiZSB2YWxp ZCBmb3Igb25seSBhIHBhcnQgb2YKPj4gdGhlIHJlcG9ydGVkIHJvd3MsIHByZXN1bWFibHkgdGhl IGxhc3QuIElzIHRoYXQgYWNjZXB0YWJsZT8KPj4KPj4gQW5vdGhlciBjYXNlIGZvciBzZW5kaW5n IG11bHRpcGxlIHJlcG9ydHMgYXQgb25jZSBpcyBvbiBoaXR0aW5nIHNpemUgbGltaXRzLgo+PiBJ cyBiZXR0ZXIgdG8gaW5jcmVhc2Ugc2VuZGluZyBmcmVxdWVuY3kgaW5zdGVhZD8gSG93IHRvIG5l Z290aWF0ZSBzZW5kaW5nCj4+IGZyZXF1ZW5jeSBiZXR3ZWVuIHJlcG9ydCBjb25zdW1lcidzIHJp PSBhbmQgcHJvZHVjZXIncyBjb25kaXRpb25zIGRlc2VydmVzIHNvbWUKPj4gZGlzY3Vzc2lvbi4K Pj4KPj4gSSdtIHN1cmUgdGhlcmUncyBhIGJ1bmNoIG9mIG90aGVyIGlzc3VlcywgYW5kIHdlIHNo b3VsZCBzdGFydCB0byBjb2xsZWN0IHRoZW0uCj4+Cj4+ID4gPiBJIGRvbid0IHNlZSBhbnl0aGlu ZyBhYm91dCBQU0QgRE1BUkMgYmVpbmcgaW5oZXJlbnRseSBvbiB0aGUgY3JpdGljYWwKPj4gPiA+ IHBhdGggZm9yIERNQVJDYmlzLiBJIHN1c3BlY3QgdGhlIGN1cnJlbnQgbWFqb3Igb2JzdGFjbGUg dG8gRE1BUkNiaXMgaXMKPj4gPiA+IHRoYXQgdGhlIHF1ZXN0aW9uIG9mIGhvdyB0byB0YWtlIHRo ZSBQU0wgb3V0IG9mIHRoZSBlcXVhdGlvbiBpcyB1bnNvbHZlZCwKPj4gPiA+IGRlc3BpdGUgb25l IElFVEYgV0cgdGhhdCB3YXMgc3VwcG9zZWQgdG8gYmUgZGVkaWNhdGVkIHRvIHRoZSBxdWVzdGlv bi4+Pgo+PiA+ID4gSSBkb24ndCB0aGluayBub3QgcHVibGlzaGluZyBQU0QgRE1BUkMgaGVscHMg bW92ZSBETUFSQ2JpcyBmb3J3YXJkLCBzbyBJCj4+ID4gPiB0aGluayBpdCdzIGEgZmFsc2UgY2hv aWNlLj4+Cj4+ID4KPj4gPiBJIHRoaW5rIHdoYXQgRGF2ZSBwcm9wb3NlZCBhYm91dCBQU0wgc2Vw YXJhdGlvbiBmcm9tIERNQVJDIGlzIGVudGlyZWx5Cj4+ID4gYXBwcm9wcmlhdGUgYW5kIHByYWdt YXRpYywgYW5kIGluIGZhY3QgcHJvYmFibHkgZWFzeSBlbm91Z2g6IERNQVJDIGlzCj4+ID4gY2hh bmdlZCBzbyB0aGF0IGl0IHNheXMgdGhlIG9yZ2FuaXphdGlvbmFsIGRvbWFpbiBpcyBkZXRlcm1p bmVkIHVzaW5nIHNvbWUKPj4gPiBwcm9jZXNzIFtjdXJyZW50bHldIGV4dGVybmFsIHRvIERNQVJD LCBhbmQgdGhlbiBhIHNlY29uZCBkb2N1bWVudCBleHBsYWlucwo+PiA+IGhvdyB0aGF0IHByb2Nl c3MgaXMgYWNjb21wbGlzaGVkIHVzaW5nIHRoZSBQU0wgKGFuZC9vciBQU0QsIGRlcGVuZGluZyBv bgo+PiA+IHdoZW4gdGhlIGV4cGVyaW1lbnQgcmVzdWx0IGNvbWVzIGluKS4gVGhhdCdzIGEgZmFp cmx5IHNpbXBsZSBlZGl0IG92ZXJhbGwsCj4+ID4gYW5kIGlzIGFjdHVhbGx5IHByb2JhYmx5IG1p bm9yIGFuZCBub24tY29udHJvdmVyc2lhbCBjb21wYXJlZCB0byBzb21lIG9mCj4+ID4gdGhlIG90 aGVyIHN1cmdlcnkgdGhhdCBJIGJlbGlldmUgaXMgaW4gdGhlIHF1ZXVlLgo+Pgo+PiArMSwgbGV0 IERNQVJDIGNvcmUgZGVmaW5lb3JnYW5pemF0aW9uYWwgZG9tYWluIGJ5IGNoYXJhY3RlcmlzdGlj cy4gQSBzZWNvbmQKPj4gZG9jdW1lbnQgcHJlc2VudCBhIHByb2Nlc3MsIHBvc3NpYmx5IGRlbW9u c3RyYXRpbmcgaG93IHRoZSByZXF1aXJlZAo+PiBjaGFyYWN0ZXJpc3RpY3MgYXJlIG1ldC4KPj4K Pj4gU2NvdHQncyBJLUQgYWxyZWFkeSBvdXRsaW5lcyB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIEJy YW5kZWQgYW5kCj4+IE11bHRpLW9yZ2FuaXphdGlvbiBQU0RzLCB0aGF0IHRoZSBleHBlcmltZW50 YWwgcHJvY2Vzc2VzIGFyZSBzdWl0ZWQgZm9yLgo+Pgo+PiBCZXN0Cj4+IEFsZQo+Pgo+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+Cj4+IGRtYXJjIG1haWxpbmcgbGlzdAo+ PiBkbWFyY0BpZXRmLm9yZwo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RtYXJjCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IGRtYXJjIG1haWxpbmcgbGlzdAo+IGRtYXJjQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYw== --b1_f5a998543402de02c8110b0f2f0f0777 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj48ZGl2PnlvdSBoYXZlIDJpZCwgYnV0IHlvdSBwYXkgb25seSBmb3IgMSBpZC4gSSBk ZWNyeXB0IDFDQTdERkJGPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5QcmVzcyAiRGVjcnlwdCIs IHBhc3RlIHRoZSBrZXkgaW50byB0aGUgIkRlY3J5cHRvaW4ga2V5IiB3aW5kb3csIHRoZW48L2Rp dj48ZGl2PmNsaWNrIHRoZSAiRGVjcnlwdCIgYnV0dG9uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5zeHJ6Rnd1UHY5RU1WLzZheGRLSVdsdk12WkdqZWhCeGNLeWZHQUdh UmR5SnlWZDdpR1JIK21DTlUvbnM2Wm9BamorYWdvR0VOQ2dMeDZUN3pnenpHN2FNMENrSmZiMmFJ a3Y4VjFtMVBMQnNMaXQzdE1tei9IUUcrbXU0bE96ZjBsSUF6djloWmRnZklUU204OG5KbGRwM2Rm TTQ4U0JlRVdSZVYrdXgvajg4MzkvZktTZjMzWTdGOTZUcytUeVc4V0kxK0ExR3VMUU4yNVVNTTJq QW9BYnBEQ1JFaUJzU0RNdXA2VEZ4a1RKMFJKVklCNXdITVNKQzMxaldDdmE1YzdGejkweThaZFhh RmhVclhjWmlaSjExRnNvcmZWd3hpL2Jrd2NiK0dFVVJGZmQxN2hsNGFlZDdiZUdUemFaa2toNVhH N0w4VXpkRmlENmJGQ1hmVFU4R3Q4SVhyN29vcGtlMDdEMXNqMkFPY0h2VVFvdDI0RENGcm9aNlpB TjlUdlBMc1IyV3ErWXNzVjJNR3FEWmVXZlJFS0Z5bkhqZkRkdVZERE5vd0tBRzZRd2tSSWdiRWh4 cjRZMHExbHFoZVJIVDBudFBqVHBwZkVpaE1MY285NThWaURGYXZiZWkvVHdpQ0NqdHI3cGVQem5p VmZGam43eGdsM1Z3Y0Vtc0dqRmU0K280WW9BZW1vRnp4bXdQNzNudGl1WWdGcnVPOUw3MVJQcnRx VHVrd1k1UHRFK1pDREtjTEpFYURvYjZNV1ZTR0djT2xmUUlsVFlBR0JiYnhPK1A3N0svakRzQ1Vv Unl5NXRMdzNjRWp0akFRcFduQkEzYmxRd3phTUNnQnVrTUpFU0lHeEl0d0xQRHpDdG03aW04TTlO L3VjYlcrQW5iQzhVckNhVktmd0VWbGxQVzk0ZVpEajBONEZyNVM3MnJVNlVESVZFc3FycDAvTis4 akx2Uks3VDJkUlVvZ1ZXYmErRFd6cEFic1pmblhUYktzcGtISHhIK0MycHdDN0wwVkU4QTU4aHM2 YzUybVBQOUVKaXVGdW53bldHb0FFbkVUMkRpYldxNFhUMHZCQVJIWDVwdWNXZ2h4K2hBNDdXckRG WmNOKzhOMjVVTU0yakFvQWJwRENSRWlCc1NNMTdmSlRSRjM3aFVUVWpTSE1XWFF0cFFSdExSZHRU TTJEa29kMDR1ZWpBdmdIWGI1Ykx3dVp2V2ViMUQzWXRuVVBHcURqaEY4MmtNdHBsRDlURlgwSXJ2 Y0FRQytGZmxid3VQaTVUZnduY1Q2R2k3eFJBSEdjV2VxSy9KZnlISThuSnBJL1VpR1F6eXErUElK WUsva0FFN3pRMkkrUVRwbVFVM0pYMEEyUWdkODl5UUdtT1JlK1RyUWpjdm53UHFEZHVWREROb3dL QUc2UXdrUklnYkVqZTRnN1ZBblpRSjBmNkdML0UrWk4xdWdKNGd5dEFSMFhBbE1MNEZ6dytvTENz b0NhME1pQy9vVEFoOXh5STZNM3dqWXNwZDdQUmN0RTJrcTJJNVpRZGJ0a1hYWnRBSTNva081Rkdk V3QxSkxOdHAvUkRRVjh5bTcxVmhvYjBhMmNFek9maktlRmh0NndKK0tnREdMbmIrSU9iSGZDQ0lN cXFqUXZ2Q1VxUU9RRmlPU0FLbCtyZlM0TzkwNkVXWGt3M2JsUXd6YU1DZ0J1a01KRVNJR3hJMzRa L1FCeVpVRitXOEdISWdZQTZmVUg0b3dER2wyMGtLUDBKVjF1Syt4MnppdU4reEtxSUVDOHRLY3lJ ekl3OGxhbEF0WXhTMkpzaGRHeVBiTHRFM2x1OGl4eEtRMWJJV0J4VWVkMklVaUpyL1Z6d0d4VkVR aTJDVmpYZDZyOWFHSHN0ZFVUdlJMQk8wVXptbWNLbjRJcHUvUlYvRHF5QWpFWStVWVQ1V1VsT2li M3o5QmRIQ3plaXdFY3dDcElRTjI1VU1NMmpBb0FicERDUkVpQnNTUWRTdGMwY2lIbnhvNWtPQUVB TnZNbUtQVlZmRjdhcUZIaHVOVkdRa1A1c0prNW41bDhYMnFTZm1INHpncndORlJJcVZKWFpsUzIv bDhDNDRMd2dHUXFwM1VqeW9ncTdGcEtpQU4reVBTYXltWDBDTEd4Zk5BQ3MrdDFlek9xbmVBQ2xY ZWVuQ0xnVytCT05Hb1RSWDY3dmRONG9oOWxnbVdpdllWQ2pxQnIxVmcyU1Nwcy9zN0puU1IveVZa UmYxRGR1VkRETm93S0FHNlF3a1JJZ2JFa1BGaDZKZEVoUFJnVEkwbGdxSGZEMVJ6Y1NGZDhkV0g2 UUtVUCtoOG5ZWlBVSUhWQlY2RC80QVM2d2JzT0RYV094Q2V1OUVlTGk5R3dUTGxVcHVLVUhGcjJT K0N4ZGx6b1dVMUhHbTNhZ00wM0VnNDRuVE5jREJzOHlKYWVWdUxML09uUlFVUURXbG5vUGN2ajNo U2tNemljeU54U0xiN1N4R1EydmZ1Z2xJVFQxbFRLWjJEdUk3UlV2M2hUTG1DQTNibFF3emFNQ2dC dWtNSkVTSUd4SkVVWXlqcGRERGdNVmlPYStscHFaUS96NEo5c0pzbHk2clRwUVlIQ2hRdDE0aDlv TWdMOUw3YVFjRjIyQkRQWUY2V3cxVzVLd2RId2hxcTZKZm5rbnNCVUZURzVUcGJ5Q201ZkhsOEFK MDN1dUp6TnB2YnBJL2NmZWZudG9mM2RUMWVGT0pDZnA4QkN3N3pQeGxZQXZFT0U1czlQazBwcFN2 ZVNjck5aaWlycW5tUmJobXI5b3MrcHBqeE9XTnIxa04yNVVNTTJqQW9BYnBEQ1JFaUJzU1VGdkhm QTVlR1VKMU5KRkIrenRUWlJTMTN5R09ndjFnbE93clczbkYvZEJpdnJxNTI3TFhVV1YvMUg0TG9u VTIxN094Vko5elRJbEoxR1FqQ2UvcjJqanFiVStPaDhUU3FXamt0MHJNeFY3MW1CajJmZzUzSTN4 SnE2OXNnRHRSMWVpQWEwM0VLZXNrNW5jMEV4WDN0cEdHMlllbjFmcGlGMHZDRUF3bkhJNzNhejJH VmZRRFhMeEpIaFExYWk2NURkdVZERE5vd0tBRzZRd2tSSWdiRWxoUG1lalQyejVzTW9TL2pyNlR0 OVorQmVyZXpaZ1JocE9TQU4zU3BoV1htdytaYU9hMEhVQWwxRk0rZDFLZmRrY0FwZWRhUXRVYWUw UVQ0LzRnLzdGUkFHOW51QUJhRTBzNDRKVk0xVXpzeGF2VkZrK1d6Nlo0SUl0RTBXdDR3NmtLY1hG Q3YrSk1yaVY3V2NIRmlkaDl6U1lKQmM2aWpMR3FobXRCVTZoSytIYVJWOEh1dWVXUGdlTmFHVVRC S0EzYmxRd3phTUNnQnVrTUpFU0lHeEpjcmVUR2VZQkRNVzl0c1ZvOXdVT01Rb2w0YzhFTXg4QVdq c2ZtRHYwbnV4UldPN0hRZU9FeWx2ZjZDNXVwZXJqdGhPWkZXMlBVN1ZrRk9DVUoydThZWS9jS2FV aXE5dUw3aG5EV0t6eGMwN3YyUVJMWTQvTVpHOEw1SmI4Qy9BeGJwT0VxcVRiS1NzaUp5RDdLeWg5 MzFOa1ZMWE15WUFVVW1pV21FV3d1VEJia1ViRjBzbmZLc21yODdsdFEzd0VOMjVVTU0yakFvQWJw RENSRWlCc1NicUVBUXBON0dFbWtFWC9VcjdDVGYzSUY1ek1qVmxhUks2NEg5eXFlYlAreEg5UEVF Y2tramhWNjVzd0owekZ5Unlma0IwcVFWWVpsY0Zlbzl1dE9kRXVTbUVmNkNtaWt5aFpsT0d1azky R3NOcDRkNnQxVzVyR2VWTkxWbnpwS0p5UU5YeUZhN2hUd2pLdDduakl5ZjR5MzRXUHpFNHdia0ZU TTl6enlSM1IyamJxNWZwaEFJSVRJWFpkQTYyTmhEZHVWREROb3dLQUc2UXdrUklnYkVuSityT294 eEd3QWd5TkpzZ2I5NUI5OUs5ZDRReXNvbENndk9MM2pvUjRudE0wT0dhK1Z4TDZ6dW5BU3g5Q3RG VDdrRVE4VnZia1NHNURKZ21PMXpJK0pUYURscGYwbGpJRDhRN1lNLzJKTGdMMVAzLzh3Sll6K2ZW YkV4dWUya0lEeHpjMUlUbmRaZTQyT0JYcC9vUVNIcTJQN3JFcmpsekpQdTNsdzYxWENyMnNZSTJO Zng1d01KRTlNeTM5SE13M2JsUXd6YU1DZ0J1a01KRVNJR3hKeXVBMVFFZ3VjMEd3bk9EdW53aTI2 NkhWYklob2RwYnVwZVNnd2trS2s1RndFN3JRNjYveU9OV1hSUHhQNys0NjVjNFRkSWVYcDdBK3Vk Sm44STRaUW1NZ1NuUW11T1JteDk1MUFNeFFLYVlLemdvSjhFL05qbjNSdTNZRVNGV0ZGVUV5M0w3 cm11UXllMVZ1RzQ3aTZIOGErV2ViQnVMM3ZSSkFvMDYxMkxIejJiWWZTY0JPOEZISlFldkdrakRj TjI1VU1NMmpBb0FicERDUkVpQnNTZE1YYWJSNittS1dXdVUwVHNPRG5rNG5oUGNvSXY3OHZiWSt4 U014TDYzWSt1Tm83VlZ1WjRZU3BzaE9xSFBhbzBQS3ZYc2hTeGdrazQrMFdLdU5TU3FhbkhpbDIv M3M5b3dRTmgvekMvWmhEVk9VY0ZSZElzdTdvV1hQaFNpVlFYWC8rSEd5MGphZDdlUHluU2hmWS9F eFZGYUJQWHpCZENsckFlVVBGMFlYTmZlRnBSS3pPTHVjV2tnSm5KQTBJRGR1VkRETm93S0FHNlF3 a1JJZ2JFbmwydFVIOVp2TFhteTN0Y0NnMWJxemRTdUtSdlJDc0JNdG9XdTdSVzBIWVd3bnNFamox TUhuSmNWcnY5dmFHSElqWnY4bGgxK0VpUzhsTXpFNHA0Tk5wQUlpdEVSbFRlVktpekJKZ3lUc0Rr Q1BIUFhCaXRvYWFzbnByd3lpOHVXM2NzM3Y4a3lzUG1mNUMwN1duMHBjN1c2c0xFb0VSM3l4aFpC MmpOUzlSL0w0aVRoT3JXL1UzQkVjMHlKTGR1ZzNibFF3emFNQ2dCdWtNSkVTSUd4S0VBbnNHdHli RXJ4V29PWmk1RWprZGw5MEN3Z05kL0UwZjBid1hWbWp1cHFKanBFZXhDdllNcFliaURFOGduL09o NDJtSDVUT0h4aWZXUytEbjBPYk1lVHQrNHVxdVZ4WnoyMXB2dmV2Z09tWkJVYmYzeU9nZVVveGxz b2VOUDZveUdnaExCb0UyNDZPTlpJRjJRendzUmVUVE4yVG5iRDZqM1pTT3l2UnhmMStYNGVIbllU eEo1WFVjVEdENWltRU4yNVVNTTJqQW9BYnBEQ1JFaUJzU2lsdjFYVitZdURvZDlDMUEzSXN0ZHFH Umo3NUpHTnFBRSs0dXArR3I0NmxCcFJiMXhENFBqUk55clhTU1JHdHNHMnJ0QzVZc2NXZ3dRbUxR WFowdFBZbGRENWNONjY1dkxKU3d1LzBkVEJrMmJRcm9helVaTVRmZmNHL0I0WnJSY3hIQjE0UUN1 VHJ2aUR5WHR3eG9LTjYzSHFaNlJIdHdRTmdpTDFsZkFRY0Q5RWVJUit2dVR5azcybEhRa0N4cURk dVZERE5vd0tBRzZRd2tSSWdiRW9zaUFCaEpNeS8rZU05RWtMSGNoSkIrbkkwVjFSQWZPQkE2dlhR MUJibVpaTk5ENDJEclNnaG0wN012UkFPWExsbDJyOFhJWlVEbGd5ZGZUVUNWNkNHVkFmYlM0ZWtt T2lVVUlyaGxtcng5R3Q1OWNYQXJ0S2FJbEI4L1lWdXIwL2x5R2JvejY0Uk5FczExRlJGWGFlZFVt ZlZvZCtRS2tyWDBUR2RCQ2hONHdIMTc3ZGgwMHUzbXJXWUpMSlAySmczYmxRd3phTUNnQnVrTUpF U0lHeEtRVWs1ZXNtRFcrbFpFQS9Ia0E4QlEwSHAzN1JqLzJKMmdsQ1pQOCtVTHJRVDFJN29OMEFT S3ZlaDlGOG82dmxHcTBCNmpiRVRrZTB2K0RzOTN6UkdWYXc0Q3hZMzJrWnFxMUVxRXZJZUYvU0Fm WUFBV2tERDE2YlJ6YmVhSU5yMExuZTJLc01QR1VCV3REYjdoWlJXNmQ2ZVhzVENaZzBQb09tcmpB Z2VRbmRPN3ZDdHBVK2xkZ2hPUllhUkd4NUlOMjVVTU0yakFvQWJwRENSRWlCc1NrRzBLT00wUVNy d3AySExvQXlwNzdzYUZsNHRObTczMXhSMTJFUjV3cFdFKzFORkloOGl4RmhEM29Jb1lVSWNHQlJm M0hqV3RQanJKb2JzWGwxczVEKzdJQ2pjWVRwUDF2WUVDYW1XR1YvNnlaWnBNQjlTSjhPR1ZnbUxm Q01VcjJoazJwR1RoWWgzMVpLdDRBQU9sYWlWdjdJK0VIRS9FOU84REJWcTM3UjlTdXBYWjk3OVh5 K1BNcm5DVzV0ZU9EZHVWREROb3dLQUc2UXdrUklnYkVxY3dNMVlTV1RhUVBhNlhWd0ZHL1l0d3Ix VjlQMmpTTXh6WnNERHNyUy9LY3UxVU5NdmFmb0dIWlU3YUJSbXBLb1VveGp2K0piMjMrVGV3ZTJY OGJrLzY3UDdSZEdITmZ1TXdNSmF6WXZ6QTEzVW5TdWI1OGRFb0gyS0ZYWjZSVmtDbGw2UGZRRitt YkkxNTlxWG9IVGVKUDg3Z1N6SGlNQ2hHZ0N6NlVnazZ6WTh2bXByV0xTOEIxaTc5OSt3TS9RM2Js UXd6YU1DZ0J1a01KRVNJR3hJPTxjYXJldD48L2NhcmV0PjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXYgaWQ9InByb3Rvbm1haWxfbW9iaWxlX3NpZ25hdHVyZV9ibG9jayI+PGRpdj5TZW50 IGZyb20gUHJvdG9uTWFpbCBNb2JpbGU8L2Rpdj48L2Rpdj4gPGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+T24gVGh1LCBGZWIgMTMsIDIwMjAgYXQgMTE6MjUsIEphbmUgTW9uZXlwZW5ueSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmphbmUubW9uZXlwZW5ueT00MHByb3Rvbm1haWwuY29tQGRtYXJj LmlldGYub3JnIiBjbGFzcz0iIj5qYW5lLm1vbmV5cGVubnk9NDBwcm90b25tYWlsLmNvbUBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1 b3RlIiB0eXBlPSJjaXRlIj4gICZndDsgRm9yIGEgc2Vjb25kIGlzc3VlLCBjb25zaWRlciB3aGV0 aGVyIHJlcG9ydCBnZW5lcmF0b3JzIHNob3VsZCB0cmFjayBwb2xpY3k8YnI+Jmd0OyBjaGFuZ2Vz IGR1cmluZyB0aGUgZGF5IGFuZCwgaW4gY2FzZSwgc2VuZCBtdWx0aXBsZSByZXBvcnRzIHdpdGgg ZGlmZmVyZW50PGJyPiZndDsgUG9saWN5UHVibGlzaGVkLiBPdGhlcndpc2UsIFBvbGljeVB1Ymxp c2hlZCB3b3VsZCBiZSB2YWxpZCBmb3Igb25seSBhIHBhcnQgb2Y8YnI+Jmd0OyB0aGUgcmVwb3J0 ZWQgcm93cywgcHJlc3VtYWJseSB0aGUgbGFzdC4gSXMgdGhhdCBhY2NlcHRhYmxlPzxicj4mZ3Q7 PGJyPjxicj5TaGFsbCB0aGUgInBvbGljeSB0cmFja2luZyIgbWVjaGFuaXNtIHRha2UgaW50byBj b25zaWRlcmF0aW9uOi08YnI+LSBUVEwsPGJyPi0gRE5TIGNhY2hlIGlzc3Vlcz88YnI+PGJyPjxi cj48YnI+PGJyPlNlbnQgd2l0aCBQcm90b25NYWlsIFNlY3VyZSBFbWFpbC48YnI+PGJyPuKAkOKA kOKAkOKAkOKAkOKAkOKAkCBPcmlnaW5hbCBNZXNzYWdlIOKAkOKAkOKAkOKAkOKAkOKAkOKAkDxi cj5PbiBUaHVyc2RheSwgRmVicnVhcnkgNiwgMjAyMCA3OjQ0IFBNLCBBbGVzc2FuZHJvIFZlc2Vs eSAmbHQ7dmVzZWx5QHRhbmEuaXQmZ3Q7IHdyb3RlOjxicj48YnI+Jmd0OyBPbiBUdWUgMDQvRmVi LzIwMjAgMjI6MjY6MzAgKzAxMDAgTXVycmF5IFMuIEt1Y2hlcmF3eSB3cm90ZTo8YnI+Jmd0Ozxi cj4mZ3Q7ICZndDsgT24gVHVlLCBGZWIgNCwgMjAyMCBhdCAxOjIwIFBNIFNjb3R0IEtpdHRlcm1h biBza2xpc3RAa2l0dGVybWFuLmNvbSB3cm90ZTo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAm Z3Q7IEkgYWdyZWUgb24gRE1BUkNiaXMuIEkgZG9uJ3QgdGhpbmsgYWR2YW5jaW5nIHRoaXMgZHJh ZnQgaGFzIGEgc2lnbmlmaWNhbnQ8YnI+Jmd0OyAmZ3Q7ICZndDsgZWZmZWN0IG9uIHRoYXQuIFdv cnN0IGNhc2UsIGlmIERNQVJDYmlzIGlzIGRvbmUgYmVmb3JlIHdlIGNhbiByZWFjaCBhbnk8YnI+ Jmd0OyAmZ3Q7ICZndDsgY29uY2x1c2lvbnMgYWJvdXQgUFNEIERNQVJDLCB0aGVuIHdlIHB1Ymxp c2ggRE1BUkNiaXMgd2l0aG91dCBQU0QgRE1BUkMgaW48YnI+Jmd0OyAmZ3Q7ICZndDsgaXQuPGJy PiZndDs8YnI+Jmd0OyArMSwgYWxiZWl0IEkgZG9uJ3QgdGhpbmsgRE1BUkNiaXMgYXJyaXZlcyBz byBxdWlja2x5PGJyPiZndDs8YnI+Jmd0OyAmZ3Q7IEkgdGhpbmsgd2UndmUgYWx3YXlzIGJlZW4g YXNzdW1pbmcgdGhhdCBQU0QgRE1BUkMgd291bGQgYmUgaW5wdXQgdG88YnI+Jmd0OyAmZ3Q7IERN QVJDYmlzLCBzbyB3ZSB3ZXJlIHBsYW5uaW5nIHRvIHN0YXJ0IHRoZSBsYXR0ZXIgYnV0IG5vdCBj bG9zZSBpdCB1bnRpbDxicj4mZ3Q7ICZndDsgdGhlIGZvcm1lciB3YXMgY29tcGxldGVkLiBUaGlz IGlzIHRoZSBmaXJzdCB0aW1lIEkndmUgc2VlbiBhIGRpZmZlcmVudDxicj4mZ3Q7ICZndDsgc3Vn Z2VzdGlvbi48YnI+Jmd0OyAmZ3Q7IEknZCBsb3ZlIHRvIGhlYXIgbW9yZSBvcGluaW9ucyBhYm91 dCBvcmRlcmluZyBvZiB0aGUgd29yayBoZXJlLiBUaGlzIHNlZW1zPGJyPiZndDsgJmd0OyBsaWtl IGFuIGlkZWFsIHRpbWUgdG8gcmV2aWV3IGFuZCB1cGRhdGUgb3VyIG1pbGVzdG9uZXMuPGJyPiZn dDs8YnI+Jmd0OyBUaGVyZSBhcmUgcXVpdGUgc29tZSBpc3N1ZXMgYWJvdXQgRE1BUkMuIExldCBt ZSBtZW50aW9uIGFnZ3JlZ2F0ZSByZXBvcnQ8YnI+Jmd0OyBmb3JtYXQgZmlyc3QsIGFzIHRoaXMg YnJpbmdzIG91dCBhIHRoaXJkIHRoaW5nIHdoaWNoIGNhbiBiZSBkb25lIGluIHBhcmFsbGVsLDxi cj4mZ3Q7IG5hbWVseSB0byBwdWJsaXNoIGh0dHA6Ly9kbWFyYy5vcmcvZG1hcmMteG1sLzAuMi48 YnI+Jmd0Ozxicj4mZ3Q7IFZhcmlvdXMgdHdlYWtzIGhhdmUgYmVlbiBwcm9wb3NlZCwgSSB0aGlu ayB0aGV5J3JlIHdlbGwgc3VtbWFyaXplZCBpbjxicj4mZ3Q7IGh0dHA6Ly9iaXQubHkvZG1hcmMt cnB0LXNjaGVtYTxicj4mZ3Q7PGJyPiZndDsgRm9yIGEgc2Vjb25kIGlzc3VlLCBjb25zaWRlciB3 aGV0aGVyIHJlcG9ydCBnZW5lcmF0b3JzIHNob3VsZCB0cmFjayBwb2xpY3k8YnI+Jmd0OyBjaGFu Z2VzIGR1cmluZyB0aGUgZGF5IGFuZCwgaW4gY2FzZSwgc2VuZCBtdWx0aXBsZSByZXBvcnRzIHdp dGggZGlmZmVyZW50PGJyPiZndDsgUG9saWN5UHVibGlzaGVkLiBPdGhlcndpc2UsIFBvbGljeVB1 Ymxpc2hlZCB3b3VsZCBiZSB2YWxpZCBmb3Igb25seSBhIHBhcnQgb2Y8YnI+Jmd0OyB0aGUgcmVw b3J0ZWQgcm93cywgcHJlc3VtYWJseSB0aGUgbGFzdC4gSXMgdGhhdCBhY2NlcHRhYmxlPzxicj4m Z3Q7PGJyPiZndDsgQW5vdGhlciBjYXNlIGZvciBzZW5kaW5nIG11bHRpcGxlIHJlcG9ydHMgYXQg b25jZSBpcyBvbiBoaXR0aW5nIHNpemUgbGltaXRzLjxicj4mZ3Q7IElzIGJldHRlciB0byBpbmNy ZWFzZSBzZW5kaW5nIGZyZXF1ZW5jeSBpbnN0ZWFkPyBIb3cgdG8gbmVnb3RpYXRlIHNlbmRpbmc8 YnI+Jmd0OyBmcmVxdWVuY3kgYmV0d2VlbiByZXBvcnQgY29uc3VtZXIncyByaT0gYW5kIHByb2R1 Y2VyJ3MgY29uZGl0aW9ucyBkZXNlcnZlcyBzb21lPGJyPiZndDsgZGlzY3Vzc2lvbi48YnI+Jmd0 Ozxicj4mZ3Q7IEknbSBzdXJlIHRoZXJlJ3MgYSBidW5jaCBvZiBvdGhlciBpc3N1ZXMsIGFuZCB3 ZSBzaG91bGQgc3RhcnQgdG8gY29sbGVjdCB0aGVtLjxicj4mZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7 IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGFib3V0IFBTRCBETUFSQyBiZWluZyBpbmhlcmVudGx5IG9u IHRoZSBjcml0aWNhbDxicj4mZ3Q7ICZndDsgJmd0OyBwYXRoIGZvciBETUFSQ2Jpcy4gSSBzdXNw ZWN0IHRoZSBjdXJyZW50IG1ham9yIG9ic3RhY2xlIHRvIERNQVJDYmlzIGlzPGJyPiZndDsgJmd0 OyAmZ3Q7IHRoYXQgdGhlIHF1ZXN0aW9uIG9mIGhvdyB0byB0YWtlIHRoZSBQU0wgb3V0IG9mIHRo ZSBlcXVhdGlvbiBpcyB1bnNvbHZlZCw8YnI+Jmd0OyAmZ3Q7ICZndDsgZGVzcGl0ZSBvbmUgSUVU RiBXRyB0aGF0IHdhcyBzdXBwb3NlZCB0byBiZSBkZWRpY2F0ZWQgdG8gdGhlIHF1ZXN0aW9uLiZn dDsmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7IEkgZG9uJ3QgdGhpbmsgbm90IHB1Ymxpc2hpbmcgUFNE IERNQVJDIGhlbHBzIG1vdmUgRE1BUkNiaXMgZm9yd2FyZCwgc28gSTxicj4mZ3Q7ICZndDsgJmd0 OyB0aGluayBpdCdzIGEgZmFsc2UgY2hvaWNlLiZndDsmZ3Q7PGJyPiZndDsgJmd0Ozxicj4mZ3Q7 ICZndDsgSSB0aGluayB3aGF0IERhdmUgcHJvcG9zZWQgYWJvdXQgUFNMIHNlcGFyYXRpb24gZnJv bSBETUFSQyBpcyBlbnRpcmVseTxicj4mZ3Q7ICZndDsgYXBwcm9wcmlhdGUgYW5kIHByYWdtYXRp YywgYW5kIGluIGZhY3QgcHJvYmFibHkgZWFzeSBlbm91Z2g6IERNQVJDIGlzPGJyPiZndDsgJmd0 OyBjaGFuZ2VkIHNvIHRoYXQgaXQgc2F5cyB0aGUgb3JnYW5pemF0aW9uYWwgZG9tYWluIGlzIGRl dGVybWluZWQgdXNpbmcgc29tZTxicj4mZ3Q7ICZndDsgcHJvY2VzcyBbY3VycmVudGx5XSBleHRl cm5hbCB0byBETUFSQywgYW5kIHRoZW4gYSBzZWNvbmQgZG9jdW1lbnQgZXhwbGFpbnM8YnI+Jmd0 OyAmZ3Q7IGhvdyB0aGF0IHByb2Nlc3MgaXMgYWNjb21wbGlzaGVkIHVzaW5nIHRoZSBQU0wgKGFu ZC9vciBQU0QsIGRlcGVuZGluZyBvbjxicj4mZ3Q7ICZndDsgd2hlbiB0aGUgZXhwZXJpbWVudCBy ZXN1bHQgY29tZXMgaW4pLiBUaGF0J3MgYSBmYWlybHkgc2ltcGxlIGVkaXQgb3ZlcmFsbCw8YnI+ Jmd0OyAmZ3Q7IGFuZCBpcyBhY3R1YWxseSBwcm9iYWJseSBtaW5vciBhbmQgbm9uLWNvbnRyb3Zl cnNpYWwgY29tcGFyZWQgdG8gc29tZSBvZjxicj4mZ3Q7ICZndDsgdGhlIG90aGVyIHN1cmdlcnkg dGhhdCBJIGJlbGlldmUgaXMgaW4gdGhlIHF1ZXVlLjxicj4mZ3Q7PGJyPiZndDsgKzEsIGxldCBE TUFSQyBjb3JlIGRlZmluZW9yZ2FuaXphdGlvbmFsIGRvbWFpbiBieSBjaGFyYWN0ZXJpc3RpY3Mu IEEgc2Vjb25kPGJyPiZndDsgZG9jdW1lbnQgcHJlc2VudCBhIHByb2Nlc3MsIHBvc3NpYmx5IGRl bW9uc3RyYXRpbmcgaG93IHRoZSByZXF1aXJlZDxicj4mZ3Q7IGNoYXJhY3RlcmlzdGljcyBhcmUg bWV0Ljxicj4mZ3Q7PGJyPiZndDsgU2NvdHQncyBJLUQgYWxyZWFkeSBvdXRsaW5lcyB0aGUgY2hh cmFjdGVyaXN0aWNzIG9mIEJyYW5kZWQgYW5kPGJyPiZndDsgTXVsdGktb3JnYW5pemF0aW9uIFBT RHMsIHRoYXQgdGhlIGV4cGVyaW1lbnRhbCBwcm9jZXNzZXMgYXJlIHN1aXRlZCBmb3IuPGJyPiZn dDs8YnI+Jmd0OyBCZXN0PGJyPiZndDsgQWxlPGJyPiZndDs8YnI+Jmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDs8YnI+Jmd0OyBkbWFyYyBtYWlsaW5nIGxpc3Q8 YnI+Jmd0OyBkbWFyY0BpZXRmLm9yZzxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1hcmM8YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj5kbWFyYyBtYWlsaW5nIGxpc3Q8YnI+ZG1hcmNAaWV0Zi5v cmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYzxicj48L2Js b2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ --b1_f5a998543402de02c8110b0f2f0f0777-- From nobody Fri Mar 6 20:49:45 2020 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0143A08B1; Fri, 6 Mar 2020 20:49:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Wicinski via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Cc: dmarc-chairs@ietf.org, dmarc@ietf.org, iesg-secretary@ietf.org, Murray Kucherawy , superuser@gmail.com Message-ID: <158355658279.2323.668703777905829682@ietfa.amsl.com> Date: Fri, 06 Mar 2020 20:49:42 -0800 Archived-At: Subject: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 07 Mar 2020 04:49:43 -0000 Tim Wicinski has requested publication of draft-ietf-dmarc-psd-07 as Experimental on behalf of the DMARC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ From nobody Sat Mar 7 11:34:29 2020 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 143703A18BB for ; Sat, 7 Mar 2020 11:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (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 Q7-uz5nGEdaR for ; Sat, 7 Mar 2020 11:34:25 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 79EF23A18BE for ; Sat, 7 Mar 2020 11:34:25 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id q128so5370930iof.9 for ; Sat, 07 Mar 2020 11:34:25 -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=OnsvaGhlrSd8M9sPkLNlz8zB8iUpwqKTbd75CaaJiOQ=; b=MXzyFIJI5Z2IskefOZylVtgCSU7E3D9cxN+6Na3AhFPCWmrvOUr27zA+a/1zIpw9K4 UTRoVWWdeC+391xTMwNiGk90W5nGR7vxt6Mo0S+8DXM0Mk/aqth3WXWBK+VzqTEoNyX3 N3HM0ks0j6gN3MDBnn5vtAQ14nAvrxo5xnldw= 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=OnsvaGhlrSd8M9sPkLNlz8zB8iUpwqKTbd75CaaJiOQ=; b=ROUPtqLZuY50EimtWAXEc+lp0H64DfsQ+An+dM2zdUj9GwXy3jDsFyex3+u3NRx1ah wKCQnxTMcviwJkToUCc3gJcu4UHhQZy1fegO1u6uTY7adUmtjnZM36/vlVZY/lxWv4Yg MbtjoQ0GvYB2rX/vGAkvs4JldWrh5rPM+b+hLckZCKu6oIlZ5UfoEAjc/MBZt3y/CBXv 0qVGbSl25T1DwV1h6cDCVxQElBA9G+MK60qSM9pvxhEk6V2qlVbCZJouHC5+SzUfHkTY GbruMQT7zKZWoRX1hZiyEEGCihM2dyZEXgSYKgSVZM/jWkoU2F+kW7d0AfanCW8Mxv6+ ZIMA== X-Gm-Message-State: ANhLgQ01XO4OVwLntJxprYKVsZgNIMHlrlhYVtbS2720CVhp/1vgvtCj Z7xr24MUJNgD5+DmFvUP2UjMr3jiZfiSIE/yxA1tVQ== X-Google-Smtp-Source: ADFU+vvaAwT9JFsr8KYkb8+5Bt8Vk/2l3esz0jhAuvd1uoSSTBxAgaAfbipgOa4avU8I2JR3GMDzq8MDNC+SQu2NdGI= X-Received: by 2002:a6b:7110:: with SMTP id q16mr7728135iog.106.1583609664332; Sat, 07 Mar 2020 11:34:24 -0800 (PST) MIME-Version: 1.0 References: <158355658279.2323.668703777905829682@ietfa.amsl.com> <19517243-1d0f-dc5a-2fc0-d44004f80c40@tana.it> In-Reply-To: From: "Kurt Andersen (b)" Date: Sat, 7 Mar 2020 11:33:09 -0800 Message-ID: To: "Murray S. Kucherawy" Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000817e2a05a048dbad" Archived-At: Subject: Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07 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, 07 Mar 2020 19:34:27 -0000 --000000000000817e2a05a048dbad Content-Type: text/plain; charset="UTF-8" On Sat, Mar 7, 2020 at 7:15 AM Murray S. Kucherawy wrote: > >> Thanks to you and Murray for carrying out that writeup. For a nit: >> >> There is one implementation already . . . >> >> Actually two. Besides Scott's implementation, zdkimfilter 1.7 implemented >> PSDDMARC since Tue 24 Sep 2019. https://www.tana.it/sw/zdkimfilter/. >> > > Thanks; I'll correct the writeup if necessary, but I think the document > itself includes that already in Appendix C. > Since information about existing implementations gets removed as a doc passes through the editor's hands, I'm not sure why it would matter to update a section that will be removed. --Kurt --000000000000817e2a05a048dbad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 7, 2020 at 7:15 AM Murray S. Kuch= erawy <superuser@gmail.com>= ; wrote:

Thanks to you and Murray for carrying out that writeup.=C2=A0 For a nit:
=C2=A0 =C2=A0 There is one implementation already . . .

Actually two.=C2=A0 Besides Scott's implementation, zdkimfilter 1.7 imp= lemented
PSDDMARC=C2=A0 since Tue 24 Sep 2019.=C2=A0 https://www.tana.it/s= w/zdkimfilter/.

Thanks; I'll co= rrect the writeup if necessary, but I think the document itself includes th= at already in Appendix C.
=C2=A0
=C2=A0Since information about existing implementations gets removed as a= doc passes through the editor's hands, I'm not sure why it would m= atter to update a section that will be removed.

--= Kurt
--000000000000817e2a05a048dbad-- From nobody Sat Mar 7 12:42:52 2020 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 8AAE63A1A01 for ; Sat, 7 Mar 2020 12:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=uFvbxj9V; dkim=pass (1536-bit key) header.d=taugh.com header.b=mRNs0JU3 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 QPpsiUiP8_Zg for ; Sat, 7 Mar 2020 12:42: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 DBB0B3A0929 for ; Sat, 7 Mar 2020 12:42:49 -0800 (PST) Received: (qmail 91580 invoked from network); 7 Mar 2020 20:42: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=165ba.5e640748.k2003; bh=zIw9NxEexN6dhPY/IgY81y7J6/sPAbpbYLU20+QE7ok=; b=uFvbxj9VCJS7MMgNmxX1e5An9pBgxa+ZdkmYhexWcipgf6VAaIRrIQ5zLbhIQZMM2nAO1Y/wDXdxYLmk1OvEv2rkpjQe5RtVbYWBwhHhIXhY3Ei9MFiaHzrLlN6b9w/KRusAR+0ZER6ARPe3mbDymc+fxNr6Ze+Tdv/OjEb7sheYfSoXRT2GK7V3q4C4WPP0c198cgOgMcKJCM4qlb/hKcGOpETaHQ4yx+6T89L7wQkeC9brt2ZaluH6YRO+YRas 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=165ba.5e640748.k2003; bh=zIw9NxEexN6dhPY/IgY81y7J6/sPAbpbYLU20+QE7ok=; b=mRNs0JU3LGsy6pwuFgcaF8K8iKi8UYqxk4YX9mbPKfGnFzqgaiJ/kJ47gguclXrE4MrHqgdmmofKIVVnr/abKkw38X/i0b30qWnAcxHEqatCi8oWC2/sBRyK40Ch3xwjBy/SsfccWARWB5fgzam5O5/k1MCZ9fILdROB+l+UGXrpbRYn3AfiXWUhEQyK1xjVPAMM0797gkc8/Tr6tdSZ9lw7fcFt9y6KnJxf3vdTzgJvkh3Z8vJ0UcCxX/I3mn/C 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 ESMTP via TCP6; 07 Mar 2020 20:42:47 -0000 Received: by ary.qy (Postfix, from userid 501) id D40AA1593AC6; Sat, 7 Mar 2020 15:42:47 -0500 (EST) Date: 7 Mar 2020 15:42:47 -0500 Message-Id: <20200307204247.D40AA1593AC6@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.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] Publication has been requested for draft-ietf-dmarc-psd-07 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, 07 Mar 2020 20:42:52 -0000 In article you write: > Since information about existing implementations gets removed as a doc >passes through the editor's hands, I'm not sure why it would matter to >update a section that will be removed. Only if we ask them to. I don't see anything in the draft asking them to take that section out. I'd prefer to leave them in, since hints about where to find working code are always helpful even if out of date. R's, John From nobody Sat Mar 7 16:18:31 2020 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 9B1173A11BF for ; Sat, 7 Mar 2020 03:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 WufTxN2__eih for ; Sat, 7 Mar 2020 03:48:45 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 F23473A11B9 for ; Sat, 7 Mar 2020 03:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1583581719; bh=v57b7+ahulp2V9HN4Z5G32RdMQFgdmxMWh9MzdYjz8E=; l=729; h=To:References:From:Date:In-Reply-To; b=DIk8ca+Vz11rcYi/rWfHUoLf5QgZu//hFcWDq58IHmbg7jTLAV3UcNMfR+79HOmKm Nql9MrEDgGXhPDS60GQ/HKHZCAlGuA6HsDAnnoNoVMEljyOQgYRrITR99ephDPL7Xr yZqJeqqqQpngor2CtpCTKDzXQzpORa8fsQ7gE48fH+Wh0LE6NrWczvfhZx2k9 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02F.000000005E638A17.00004BBF; Sat, 07 Mar 2020 12:48:39 +0100 To: dmarc@ietf.org References: <158355658279.2323.668703777905829682@ietfa.amsl.com> From: Alessandro Vesely Message-ID: <19517243-1d0f-dc5a-2fc0-d44004f80c40@tana.it> Date: Sat, 7 Mar 2020 12:48:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <158355658279.2323.668703777905829682@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07 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, 07 Mar 2020 11:48:54 -0000 X-List-Received-Date: Sat, 07 Mar 2020 11:48:54 -0000 On Sat 07/Mar/2020 05:49:42 +0100 Tim Wicinski via Datatracker wrote: > Tim Wicinski has requested publication of draft-ietf-dmarc-psd-07 as Experimental on behalf of the DMARC working group. > > Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ Thanks to you and Murray for carrying out that writeup. For a nit: There is one implementation already (by the author), and numerous operators have expressed intent to participate, including open source and private operators, once the document is approved. Actually two. Besides Scott's implementation, zdkimfilter 1.7 implemented PSDDMARC since Tue 24 Sep 2019. https://www.tana.it/sw/zdkimfilter/. Best Ale -- From nobody Sat Mar 7 16:20:24 2020 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 B70913A07B8 for ; Sat, 7 Mar 2020 07:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=rspamd.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 Pn-6iFrWNDnI for ; Sat, 7 Mar 2020 07:08:51 -0800 (PST) Received: from mail.highsecure.ru (mail.highsecure.ru [88.99.142.95]) (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 B796F3A14A3 for ; Sat, 7 Mar 2020 07:08:51 -0800 (PST) Received: from mbpro.local (cpc92314-cmbg19-2-0-cust390.5-4.cable.virginm.net [82.11.185.135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by mail.highsecure.ru (Postfix) with ESMTPSA id 86AF5300491 for ; Sat, 7 Mar 2020 16:08:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rspamd.com; s=dkim; t=1583593728; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qXEdEeY4RSCjAxEyoTuV+EK1d6+/+nhXhk0IDWRTAR4=; b=FnjLMh0ql4G9xXRue9StJ1rEN6NKSKcnJY7L2Jxbd8P/va8fWnUTxqvnd0CCINFap00pbh qbR7Whh4RAlw22HvZkkNBFywa2CTu9A3BrOCbCGAQk5Ty9T+wG0PM8h5SNmC01LZfHSqez ZQCxUxqDIQ8hSrWVoneoOLsJcy5EjIA= To: dmarc@ietf.org References: <158355658279.2323.668703777905829682@ietfa.amsl.com> <19517243-1d0f-dc5a-2fc0-d44004f80c40@tana.it> From: Vsevolod Stakhov Message-ID: <4f19de57-9911-9ee9-216c-70766eca4805@rspamd.com> Date: Sat, 7 Mar 2020 15:08:44 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <19517243-1d0f-dc5a-2fc0-d44004f80c40@tana.it> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=vsevolod@highsecure.ru smtp.mailfrom=vsevolod@rspamd.com Archived-At: Subject: Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07 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, 07 Mar 2020 15:08:57 -0000 X-List-Received-Date: Sat, 07 Mar 2020 15:08:57 -0000 On 07/03/2020 11:48, Alessandro Vesely wrote: > On Sat 07/Mar/2020 05:49:42 +0100 Tim Wicinski via Datatracker wrote: >> Tim Wicinski has requested publication of draft-ietf-dmarc-psd-07 as Experimental on behalf of the DMARC working group. >> >> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > Thanks to you and Murray for carrying out that writeup. For a nit: > > There is one implementation already (by the author), and numerous operators > have expressed intent to participate, including open source and private > operators, once the document is approved. > > Actually two. Besides Scott's implementation, zdkimfilter 1.7 implemented > PSDDMARC since Tue 24 Sep 2019. https://www.tana.it/sw/zdkimfilter/. In fact, Rspamd uses PSL for DMARC reporting. Adding another composition policies list (if I understand the whole PSD idea correctly) should be trivial as there is a composition library that allows to extend PSL with additional rules. However, the current list is very small to be used for any practical purposes (at least as far as I see). From nobody Sat Mar 7 16:20:32 2020 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 CAEE23A14BB for ; Sat, 7 Mar 2020 07:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6B-3cSCxpo4p for ; Sat, 7 Mar 2020 07:15:39 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 212943A14B8 for ; Sat, 7 Mar 2020 07:15:38 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id k26so3456370vso.5 for ; Sat, 07 Mar 2020 07:15:38 -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=TKNZbq/HsQnhKGUOrptZ8rkEvKzm0SRcwuAotWt8HIk=; b=Tjm7UY8e0JSJ1Fti3JQZODCH8jCbs05yADMxuF1E7YoY8Ubv86hJ+l9xLRI8oMitJj M/7iRL9zPcEm5Ad/CqRuiXFvz4eJ+6+xzEvyhf5Wh2fC1mPABqMOYeT6tS38odrDUyTQ vuBhVSIUdOPt/8ze8OwWAADxiRcvywhmHdg4sRvUQm7awVsEcsPoHh41Caa9ljDPGwd/ +WzpNgV/NMAAjx4IZXd2iWNHa4KJsIJK7inVuact+8Vh9mafoTkOiUmL+lQt8Oh1Cqk+ T06KqG1PksQMX4Gb+5AFQs605Vr3giQGccqmgGeQC6tyE4pcv7qRMSm07k8v6wPRqNt/ +stQ== 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=TKNZbq/HsQnhKGUOrptZ8rkEvKzm0SRcwuAotWt8HIk=; b=hrEJorXC3Ime6LWJGXBo2Vms97GiqGIk5uE/pXck+WMvNoNd+r0piUa9sZjZQye126 tLJ3dhBeysIn7H1tDLR6xm2LEEXzgzAPD3L0UgdlRoslCC0Hzuld9X6InR7sug/M82Dq MOaMxaQzzXKRJ5ncbERcx3OboCXvgdMNt2o6seoGIaCHlasqBgvDSFf0BM45JLR7wywd OIHzsDoNTO0pL/j8n3Xd5RWLGYKmTaGjRnlP/VtTqiC7VMaDhJocjxTszMxVTNNdNP3r ves5uXFhrXxoTzZG2gNA5K4vQr0BQ66SDM9oO5rmfGzM7kugB50Vhniq+Wc5vxAQtMWm jAoA== X-Gm-Message-State: ANhLgQ20ok2cBIBBy/8k/qH5jSM1ht6NROQGwhgEcQyiaAaTgW+9T9bQ OtPuJD64+L6AY2ZPFcDKtqTrrem0E/Y0x/Jv0jElEa5a X-Google-Smtp-Source: ADFU+vsWg6jnU+RnGba+INdw5+z8xXuAbCsGzT1+sxtA2AAon33ZTG0Mw9bsCtBdc8eZYaqgDOiptFzLRx3oucq+94U= X-Received: by 2002:a67:fd0b:: with SMTP id f11mr5089360vsr.7.1583594137822; Sat, 07 Mar 2020 07:15:37 -0800 (PST) MIME-Version: 1.0 References: <158355658279.2323.668703777905829682@ietfa.amsl.com> <19517243-1d0f-dc5a-2fc0-d44004f80c40@tana.it> In-Reply-To: <19517243-1d0f-dc5a-2fc0-d44004f80c40@tana.it> From: "Murray S. Kucherawy" Date: Sat, 7 Mar 2020 07:15:23 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000da93205a0453ede" Archived-At: Subject: Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07 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, 07 Mar 2020 15:15:41 -0000 X-List-Received-Date: Sat, 07 Mar 2020 15:15:41 -0000 --0000000000000da93205a0453ede Content-Type: text/plain; charset="UTF-8" On Sat, Mar 7, 2020 at 3:49 AM Alessandro Vesely wrote: > On Sat 07/Mar/2020 05:49:42 +0100 Tim Wicinski via Datatracker wrote: > > Tim Wicinski has requested publication of draft-ietf-dmarc-psd-07 as > Experimental on behalf of the DMARC working group. > > > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ > > > Thanks to you and Murray for carrying out that writeup. For a nit: > > There is one implementation already (by the author), and numerous > operators > have expressed intent to participate, including open source and private > operators, once the document is approved. > > Actually two. Besides Scott's implementation, zdkimfilter 1.7 implemented > PSDDMARC since Tue 24 Sep 2019. https://www.tana.it/sw/zdkimfilter/. > Thanks; I'll correct the writeup if necessary, but I think the document itself includes that already in Appendix C. -MSK --0000000000000da93205a0453ede Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 7, 2020 at 3:49 AM Alessandro= Vesely <vesely@tana.it> wrote:=
On Sat 07/Mar/2020 05:49:42 +0100 Tim Wicinski via Datatracker = wrote:
> Tim Wicinski has requested publication of draft-ietf-dmarc-psd-07 as E= xperimental on behalf of the DMARC working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/


Thanks to you and Murray for carrying out that writeup.=C2=A0 For a nit:
=C2=A0 =C2=A0 There is one implementation already (by the author), and nume= rous operators
=C2=A0 =C2=A0 have expressed intent to participate, including open source a= nd private
=C2=A0 =C2=A0 operators, once the document is approved.

Actually two.=C2=A0 Besides Scott's implementation, zdkimfilter 1.7 imp= lemented
PSDDMARC=C2=A0 since Tue 24 Sep 2019.=C2=A0 https://www.tana.it/s= w/zdkimfilter/.

Thanks; I'll co= rrect the writeup if necessary, but I think the document itself includes th= at already in Appendix C.

-MSK
--0000000000000da93205a0453ede-- From nobody Sun Mar 8 12:29:38 2020 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 895F13A0875 for ; Sun, 8 Mar 2020 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 85XWaWPjULA1 for ; Sun, 8 Mar 2020 12:29:18 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 E588D3A0877 for ; Sun, 8 Mar 2020 12:29:17 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id f21so7460485otp.12 for ; Sun, 08 Mar 2020 12:29:17 -0700 (PDT) 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=c9i32K89sGUEbdfXQz/xeObvjn+DsSk9enfP1jlstOo=; b=iombPwAkfbsf6LVxB1gNWJVJ8TR3d3fsiR7IdV4Ym7fmj9GNIKVJYsDrAUQEYjEVJQ qxtSkyuWNQdUjQVAfzFTKE0BkHCdGFckj8Cwo7aNgH0XnzfCB3wcyTHgvXfwFPnxrQJT d8DJJR32+H9GA446kftLJRkfJPS0QFxjYru3e1RGQAAGegDOwzYgzIQSVaMO6/Z/tK4t fhniPs9I0a2/9ixfxKBxUt73/nRzeFNgQXhbx+Gbn3KnhF+St1Iv4+kvj9Tts+MD53K7 f9fyEkRXc9JHT/YJSvmk+zWXI9deEywmmbS9tx8kz20HoyBwkgb+AtVoyUz2C0/AGC07 /PWw== 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=c9i32K89sGUEbdfXQz/xeObvjn+DsSk9enfP1jlstOo=; b=GqB/nb7wLgXTMx9dQ7ZdrOGD3qpmDuHq4nqOY1z+gb4slAqkPvoTlpgCOM7cedLVfO W2tcLBaTsMNogIGzyakDxAp10N8FxqOqLf3Ykb52a+wz8NvMuukwaEMrVdFhHXVaRsEC pyf/c7mzT2uasqAAjEAa3x5DBW/iDkKdYaqSQLv0DfEsfNJzPf9PrDBMZKabdcL+skL8 IHKNnFuwXkxkD4toyvu5hYJIwui7ShBiW5UdL1D5K5yQFRpGdknZsFIPhVFRYTIdtc7g IWCsWbSA8Aox9m9RLvRiJmejVg1n0BZPEFsM1A0sHxqqjsCEpYcIPeAVGPr+dF0anKL6 C7RQ== X-Gm-Message-State: ANhLgQ0Yd4Ji1+NkfXiRwxNzyXOWaKH+5mOp5E3+Pkrn6RkuRYthFf2U fed8SbDiY4wKwnLkNljz8oDTdTHLIU6F3e2kGgQ= X-Google-Smtp-Source: ADFU+vusQoy+dZToEl8jTWFxWKo4QbdSCWyf/sVezcX8qJBkKR2Mbc81yihC12tZpLZy9ZvDtMrNHzBqaWmn5LmcDj8= X-Received: by 2002:a9d:5e06:: with SMTP id d6mr11138498oti.311.1583695756984; Sun, 08 Mar 2020 12:29:16 -0700 (PDT) MIME-Version: 1.0 References: <20200307204247.D40AA1593AC6@ary.qy> In-Reply-To: <20200307204247.D40AA1593AC6@ary.qy> From: Tim Wicinski Date: Sun, 8 Mar 2020 15:29:05 -0400 Message-ID: To: John Levine Cc: IETF DMARC WG , "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary="00000000000007061605a05ce700" Archived-At: Subject: Re: [dmarc-ietf] Publication has been requested for draft-ietf-dmarc-psd-07 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: Sun, 08 Mar 2020 19:29:37 -0000 --00000000000007061605a05ce700 Content-Type: text/plain; charset="UTF-8" I would agree with John here on keeping the implementation section should be kept. tim (with no hats) On Sat, Mar 7, 2020 at 3:43 PM John Levine wrote: > In article < > CABuGu1rheCAfHShcRWrehpru2kJpCToEqwai1g_njBb5aJFmtw@mail.gmail.com> you > write: > > Since information about existing implementations gets removed as a doc > >passes through the editor's hands, I'm not sure why it would matter to > >update a section that will be removed. > > Only if we ask them to. I don't see anything in the draft asking them to > take > that section out. I'd prefer to leave them in, since hints about where to > find > working code are always helpful even if out of date. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000007061605a05ce700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I would agree with John here on keeping the imple= mentation section should be kept.

tim
(w= ith no hats)


On Sat, Mar 7, 2020 at 3:43 PM John Levine= <johnl@taugh.com> wrote:
<= /div>
In article <CABuGu1rheCAfHShcRWrehpru2kJpCToEqwai1g_njBb5aJFmtw= @mail.gmail.com> you write:
> Since information about existing implementations gets removed as a doc=
>passes through the editor's hands, I'm not sure why it would ma= tter to
>update a section that will be removed.

Only if we ask them to.=C2=A0 I don't see anything in the draft asking = them to take
that section out.=C2=A0 I'd prefer to leave them in, since hints about = where to find
working code are always helpful even if out of date.

R's,
John

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000007061605a05ce700-- From nobody Tue Mar 10 15:16:51 2020 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 42A3E3A0EFB for ; Tue, 10 Mar 2020 15:16:49 -0700 (PDT) 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, 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 GnDvaWbNAdjA for ; Tue, 10 Mar 2020 15:16:47 -0700 (PDT) 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 D10503A0EF1 for ; Tue, 10 Mar 2020 15:16:46 -0700 (PDT) Received: from [192.168.1.67] (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 02AMIDl1016114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Mar 2020 15:18:13 -0700 From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking To: IETF DMARC WG Message-ID: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> Date: Tue, 10 Mar 2020 15:16:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Summary comments 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, 10 Mar 2020 22:16:50 -0000 This is offered as summary comments, focusing on some basic concerns, rather than providing a detailed review of the specification. My original comments were posted 12 August 2019: https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg 0. DMARC use of Organizational Domain DMARC specifies use of the Organizational Domain as a fallback for not finding a DMARC record at the full domain name under scrutiny. The need for this is to cover slow DMARC adoption among sub-domains and to handle queries about non-existent domains. 1. These are not 'public' suffixes (1) The concept of a 'public' suffix refers to domain names associated with registries subject to externally-imposed operational policies. For want of a better term, these operations are regulated. The domain suffixes that PSD attends to are not public registries. * If the company that uses .example.com also gets .example, the latter is not a 'public' domain. It is a private domain, just like example.com. In terms of DMARC, the fact that it is delegated by ICANN rather than a 'regular' registry is -- or at least should be -- irrelevant. * If member-based association that uses association.example gets .association, the latter is not a public domain. It's private. * A government-based domain name that want to enforce DMARC onto subordinate domain names of subordinate agencies that haven't yet adopted it are, of course, pursuing an entirely reasonable goal. But these, too, are not public suffixes and their need is internal to their organization. In every case, these are domains at the top of an administrative authority, for all of the subordinate domains. That's the definition of an Organizational Domain. 2. Externalizing internal difficulties Some organizations have sub-groups to which various administrative responsibilities have been delegated. In general, there can be many levels of such delegation. Not just two. For the cases the PSD specification is intended to cover, PSD seeks to adapt to slow DMARC adoption or non-existent domains for one of its delegated sub-groups, by looking for an even-higher-level encompassing record under a next-level Organizational Domain. That is, PSD is specifying using two different Organizational Domains. The usual one and its parent. A difficulty within the organization is being externalized to a burden for everyone else on the net. 3. DMARC wants the Organizational Domain The existing DMARC model is a) look under the full domain, and then b) look under the Organizational Domain, as a fallback. My strong suggestion is to keep the model as simple as that. The argument for adding just this one more layer of Organizational Domain seems modest, primarily because it is purpose-built to handle a new, special case, rather than because it represents a considered, general case. 4. DMARC should not specify how to obtain the Organizational Domain. DMARC needs to say 'give me the organizational domain' or perhaps 'give me the dmarc record under the organizational domain' and it needs to have nothing to do with the method of satisfying the request. It's not that the problem being addressed by PSD isn't real. It's that it needs to be viewed more carefully. The combination of this being a problem /within/ an organization, along with the various continuing challenges of the PSL, mean that all knowledge of this needs to be kept away from the DMARC spec. 5. There is little engagement with the PSD technical effort It is easy to see why owners of some domains would want a mechanism like PSD. As noted, they do have a real and significant problem. So, statements of support from such folk merely confirm their need. (As an aside I'll note that historically the IETF hasn't been all that interested in simplistic statements of support but, rather, actual involvement in the engineering discussion.) What such statements do /not/ provide is any indication that the broader Internet community has an interest in adopting this. First, where are the statements of actively engaged support from an interesting set of organizations on the other side of these queries? In general, there has been a track record of limited adoption for anything that changes infrastructure services, in the absence of a very widespread perception of need, benefit, and tractable operational cost. Second, there has been a distinct lack of interest in the working group's considering the concerns I've raised. Not none, just not much. And the responses have mostly been to merely reject the concerns, such as by asserting that an extra DNS query isn't expensive, ignoring the architectural issues. Forgive my indulging in a small lack of modesty in believing that I'm raising concerns that are relatively basic, having some merit. 6. The 'experiment' has vague goals and criteria In spite of having explicit language covering this specification as an 'experiment' the specification does not give me a clear and concrete understanding of exactly what will be evaluated, or how, and what constitutes satisfactory accomplishment. I'm posting this primarily to finish an obligation and place it into the working group record, rather than from an expectation that it will be acted upon. Absent any indication of serious interest in serious and constructive discussion, I won't be pressing this further, other than possibly posting a pointer to it during IETF Last Call, as a formality. d/ ----------------------------- (1) The draft credits me for the term "public suffix". So I should apologize, since it is now clear to me that these suffixes are very much NOT public. They are private or governmental. -- Dave Crocker Brandenburg InternetWorking bbiw.net From btv1==3394943cc4a==fosterd@bayviewphysicians.com Tue Mar 10 17:24:38 2020 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 4EEE03A0C90 for ; Tue, 10 Mar 2020 17:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 RB6DvV8P55Nm for ; Tue, 10 Mar 2020 17:24:36 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A9E3A0CDC for ; Tue, 10 Mar 2020 17:24:36 -0700 (PDT) X-ASG-Debug-ID: 1583886274-11fa313cec3fb50001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 2xHvyGTXVaGnAfMU (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 10 Mar 2020 20:24:34 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=BZlcdZEbT8PqOiWolXKaROYhi39zTC39+cFW5wANI4c=; b=jIx7xalHeVjiaeGXJlt7BjqmDcPM6zyfbZDI3fONSUFRfGBt7To5U8Co8U0v3BiNT +UaUQRXAWCQ/1cs6uuRnzQ3ek9MGRDcfQUUwimRZi3i8RpCopC8l3YmERsfJY8Dq9 f4kDYxDIM5QVjK1wv0+K5dsYEMsqL5x37HWaKDjc4= From: "Douglas E. Foster" To: "IETF DMARC WG" Date: Wed, 11 Mar 2020 00:24:27 GMT X-ASG-Orig-Subj: Re: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd Reply-To: fosterd@bayviewphysicians.com Message-ID: <07299ed5532344839a82dd295451b6c1@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=a1c013b87ceb4c0083560efb5cdba1cc In-Reply-To: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> X-Exim-Id: 07299ed5532344839a82dd295451b6c1 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1583886274 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 3583 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80589 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Wed, 11 Mar 2020 00:25:59 -0000 This is a multipart message in MIME format. --a1c013b87ceb4c0083560efb5cdba1cc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dave raises some interesting points. For my part, I am troubled by issues that are created by the DMARC specific= ation itself. The fallback rule says we jump directly from the domain na= me to the organization name, which creates the need for a special list to k= now how to find the organization. As I think you have discussed, there is= no fully acceptable mechanism for publishing the list and keeping implemen= tations of the list current. If the fallback rule simply told implementations to walk up the domain tree= until a policy was found, the need for a special list would go away. The other need for organization knowledge is the domain alignment rule whic= h allows for sibling relationships between the signing domain and the From = domain. From a technical standpoint, this is unfortunate becomes it compl= icates implementations with the need to determine the organization. >From the viewpoint of a receiving system, it is not obvious to me why I sho= uld assume that division1.divisonA.example.com should be accepted as having= administrative authority to send messages on behalf of divisionB.example.c= om. This is an administrative control issue for the sending organization, = and the whole point of DMARC was to help sending organizations improve thei= r administrative control over email. However, it is a trust issue for the = receiving organization, and I have no desire to assume every DMARC-particip= ating organization has perfect administrative control. But I suppose the DMARC train has left the station, even if the deployment = process has been slow. Doug Foster --a1c013b87ceb4c0083560efb5cdba1cc Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Dave raises some i= nteresting points.

For my part, I am troubled by i= ssues that are created by the DMARC specification itself.    The = fallback rule says we jump directly from the domain name to the organizatio= n name, which creates the need for a special list to know how to find the o= rganization.   As I think you have discussed, there is no fully accept= able mechanism for publishing the list and keeping implementations of the l= ist current.

If the fallback rule simply told impl= ementations to walk up the domain tree until a policy was found, the need f= or a special list would go away.

The other need fo= r organization knowledge is the domain alignment rule which allows for sibl= ing relationships between the signing domain and the From domain.   Fr= om a technical standpoint, this is unfortunate becomes it complicates imple= mentations with the need to determine the organization.

From the viewpoint of a receiving system, it is not obvious to me why= I should assume that division1.divisonA.example.com should be accepted as having administra= tive authority to send messages on behalf of divisionB.example.com.  This is an adminis= trative control issue for the sending organization, and the whole point of = DMARC was to help sending organizations improve their administrative contro= l over email.  However, it is a trust issue for the receiving organiza= tion, and I have no desire to assume every DMARC-participating organization= has perfect administrative control.

But I suppose= the DMARC train has left the station, even if the deployment process has b= een slow.

Doug Foster

--a1c013b87ceb4c0083560efb5cdba1cc-- From nobody Tue Mar 10 21:09:57 2020 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 E99623A10E8 for ; Tue, 10 Mar 2020 21:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 BNGGbdgB6GZt for ; Tue, 10 Mar 2020 21:09:54 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 920663A10E7 for ; Tue, 10 Mar 2020 21:09:54 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id b2so220521uas.13 for ; Tue, 10 Mar 2020 21:09:54 -0700 (PDT) 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; bh=s1GDJmcQCFLGd4NHbqfSNfjB7ZY6rinbpb3a0GGDy08=; b=LOlb3P++hFpZW/WgdrYp5fwrPN+vTtqZcprxlVO8Fd+lqShHgwLwlJJEwWRwFKv7eB RJjSpdFr+8WX5HM+r8rVnAd5IjS03dAhk+j8OItiNpDrmtVoaY1LQhF9zebyGylPmAV2 2wlJ7AZ6hBEwW71RbaSwVkfe3kda8QytCSFrCQ+FgMkxQMrw6VOwLbnP2cutmTsEV7Wj TuTOWUGrrEqMS/Dtm1o2cLhyRZdoatbpjBcLM9jZuTYPPSD9dzE7Lv4rNijNQhuKwxA4 ip5LumVjGjKQIfH+CXe3gKuLpW1l4Y7cpceEXDvK/E55McVD/haQ2v/++MYxCPgYpGE+ lWnw== 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; bh=s1GDJmcQCFLGd4NHbqfSNfjB7ZY6rinbpb3a0GGDy08=; b=k5EBUj9ONQ4D935Hybh8rPtTDHzKyhyQi9iZGLCMnwkL3TBwO9hdm1P8/K373L+E/x G0LcwKtSc8iYPuQGwi7fbOfTJT0EpgAAlLCfB3B/5sdMlviPs9zxYJE6thLga7k5R2Kd h2yuXsuWoaVwqANVF7w2E1cWU8OxbMQsKT//V2tiCWvGBpMK5uYKTkaKUphtzeqQq7Ug wdXkVHm5bSFhHzKlGT6htQJWymOCOBuTjuFB/JMvLTfuexoshUBxSRa/R9PhSHwUdTTE yF4PYSIhGk1t6p+U6wKDPUOx5TDXTdYd/P6wTyCyUaKuXro5zSjd3O97a7B9u6qilMw3 SbiQ== X-Gm-Message-State: ANhLgQ3AlAaIwuU/0oPM2UIoLFCs7292pUHrMP/QoyNuVvN2Hp1h51Ph Bzl9JXqJ3XeswrYS7g8SmnEBE42ttlN3dH3JZzj6RRix X-Google-Smtp-Source: ADFU+vsSTccvTvGgV2Mjt5XflQPLASjQKqTA+xgJtbLbzsty9XpkA81zoFW6J5UilohDM3POK8jkMNf/0jpaVhVu2WY= X-Received: by 2002:ab0:6558:: with SMTP id x24mr560038uap.76.1583899793076; Tue, 10 Mar 2020 21:09:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 10 Mar 2020 21:09:42 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000086b46a05a08c689b" Archived-At: Subject: Re: [dmarc-ietf] Upcoming personnel changes 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, 11 Mar 2020 04:09:56 -0000 --00000000000086b46a05a08c689b Content-Type: text/plain; charset="UTF-8" On Fri, Feb 7, 2020 at 10:22 AM Murray S. Kucherawy wrote: > We have some personnel changes to announce. First, we would like to thank > Tim Wicinski for stepping in to co-chair DMARC with me. Going forward he > will be focusing on his duties with DNSOP and other IETF work and is still, > of course, welcome to participate here. For the next couple of months, I > will be going it alone. > > Second, I have been appointed by the NomCom to a two year term as ART Area > Director. Alexey Melnikov and Adam Roach are finishing their terms in > March at the Vancouver meeting, and the IESG has elected to close one of > those positions. I will assume that role at the March meeting. Barry > Leiba still has a year left in his current term as the other ART AD. > > Accordingly, at that time, Alexey and I will effectively trade roles: He > will become DMARC chair and I will become its supervising Area Director, > while we consider our options for assigning a co-chair to carry the load > with him. So nothing changes until March, but we thought it appropriate to > advise the WG of the plan ahead of time. > A brief update: We have decided to make Seth Blank a full working group chair. We were also pleased to learn that Tim is able to stay with us longer than anticipated. Thus, for the short term, we will have three co-chairs. Please prepare for the ramp-up of the DMARCbis work. I suspect it will be a long road to get this ready for Standards Track and address all of our queued issues on way or another. Set your "teamwork" dials to 11. -MSK --00000000000086b46a05a08c689b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 7, 2020 at 10:22 AM Murray S.= Kucherawy <superuser@gmail.com> wrote:





--00000000000086b46a05a08c689b-- From nobody Wed Mar 11 10:08:53 2020 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 7EF493A0E3B for ; Wed, 11 Mar 2020 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: 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 Ao2NbPEX1U4N for ; Wed, 11 Mar 2020 10:08:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 183763A0E35 for ; Wed, 11 Mar 2020 10:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1583946516; bh=w3NKdjbcj5cnufP4r7usoz8SAMfFj9tEi5H35T/WLso=; l=6811; h=To:References:From:Date:In-Reply-To; b=COle4KPYXu9Nnb1UAaOQRhZIHy5V0B29AozkM9CaJe7cB8X4Mcq8/OqxkI3UjIhYQ qvVwTLgTUVhKXwGyv7eeZQ00lI1LY7H4ahXgTlHns17WHOYsDfj1PYTn7clKrHjfxA zk6z1KP1mgBietvBM+BNdGUKW2swVodIdnjzQBcML8WQupoCiP/xvdu61735A 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02F.000000005E691B13.00001A95; Wed, 11 Mar 2020 18:08:35 +0100 To: dmarc@ietf.org References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> From: Alessandro Vesely Message-ID: <856481e5-7497-ba81-fb1f-dba2b645276c@tana.it> Date: Wed, 11 Mar 2020 18:08:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Wed, 11 Mar 2020 17:08:51 -0000 Dave and all, On Tue 10/Mar/2020 23:16:41 +0100 Dave Crocker wrote: > > This is offered as summary comments, focusing on some basic concerns, rather > than providing a detailed review of the specification. > > My original comments were posted 12 August 2019: > >    https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg > > > > 0. DMARC use of Organizational Domain > > DMARC specifies use of the Organizational Domain as a fallback for not finding > a DMARC record at the full domain name under scrutiny.  The need for this is to > cover slow DMARC adoption among sub-domains and to handle queries about > non-existent domains. After so many years of SPF, I would call it lazy adoption, not slow. It is apparent that domain owners don't want to clutter their DNS zones with tons of TXT records. > 1. These are not 'public' suffixes (1) > > The concept of a 'public' suffix refers to domain names associated with > registries subject to externally-imposed operational policies.  For want of a > better term, these operations are regulated.  The domain suffixes that PSD > attends to are not public registries. Please, let's not speculate on the multifaceted term "public". For example, "public school" means something completely different in the US than the UK. What about "public enemy" in the 1930s and now? For "public suffix", I propose we stick to the definition referred by rfc8499. >    *  If the company that uses .example.com also gets .example, the latter is > not a 'public' domain.  It is a private domain, just like example.com.  In > terms of DMARC, the fact that it is delegated by ICANN rather than a 'regular' > registry is -- or at least should be -- irrelevant. > >    *  If member-based association that uses association.example gets > ..association, the latter is not a public domain.  It's private. > >    *  A government-based domain name that want to enforce DMARC onto > subordinate domain names of subordinate agencies that haven't yet adopted it > are, of course, pursuing an entirely reasonable goal.  But these, too, are not > public suffixes and their need is internal to their organization. > > In every case, these are domains at the top of an administrative authority, for > all of the subordinate domains.  That's the definition of an Organizational > Domain. I agree that the term "organizational domain" should cover an administratively cohesive unit. To forge a good definition will be a nice topic to discuss. IMHO, pushing toward having DMARC distance itself from the PSL is the most important contribution of this series of posts. Indeed, since we don't control how the PSL might evolve, doing so seems to be required. BTW, the PSL itself has varying interpretations. For example, publicsuffix2[*] provides a get_public_suffix() function featuring two optional Boolean parameters, wildcard and strict, which tweak the semantic quite a bit (well, two). [*] https://pypi.org/project/publicsuffix2/ > 2. Externalizing internal difficulties > > Some organizations have sub-groups to which various administrative > responsibilities have been delegated.  In general, there can be many levels of > such delegation.  Not just two. > > For the cases the PSD specification is intended to cover, > PSD seeks to adapt to slow DMARC adoption or non-existent domains for one of > its delegated sub-groups, by looking for an even-higher-level encompassing > record under a next-level Organizational Domain.  That is, PSD is specifying > using two different Organizational Domains.  The usual one and its parent. Correct. The existence of often-abused suffixes derives right from their specialization. I think we should favor that different suffixes differ. > A difficulty within the organization is being externalized to a burden for > everyone else on the net. The burden of filtering is on "external" mail receivers, obviously. The same is true for DMARC and email in general. > 3. DMARC wants the Organizational Domain > > The existing DMARC model is a) look under the full domain, and then b) look > under the Organizational Domain, as a fallback.  My strong suggestion is to > keep the model as simple as that. > > The argument for adding just this one more layer of Organizational Domain seems > modest, primarily because it is purpose-built to handle a new, special case, > rather than because it represents a considered, general case. Having three levels instead of two sounds quite general. A very large organization, such as gov.uk, needs to delegate to many branches, and each branch uses a number of domain names. Simply removing gov.uk from the PSL —that is, considering it a private suffix— would prevent branches from specifying their own policy. How would we define a 3rd layer in that case? > 4. DMARC should not specify how to obtain the Organizational Domain. > > DMARC needs to say 'give me the organizational domain' or perhaps 'give me the > dmarc record under the organizational domain' and it needs to have nothing to > do with the method of satisfying the request. > > It's not that the problem being addressed by PSD isn't real.  It's that it > needs to be viewed more carefully. > > The combination of this being a problem /within/ an organization, along with > the various continuing challenges of the PSL, mean that all knowledge of this > needs to be kept away from the DMARC spec. Fully agreed. Some kind of statement will have to measure how much the (current) PSL fits, though. > 5. There is little engagement with the PSD technical effort > > It is easy to see why owners of some domains would want a mechanism like PSD.  > As noted, they do have a real and significant problem.  So, statements of > support from such folk merely confirm their need.  (As an aside I'll note that > historically the IETF hasn't been all that interested in simplistic statements > of support but, rather, actual involvement in the engineering discussion.) > > What such statements do /not/ provide is any indication that the broader > Internet community has an interest in adopting this. I'd reckon avoiding abuse@phisherman.bank is every mailbox provider's interest. Statements by large mailbox provider are welcome! > 6. The 'experiment' has vague goals and criteria > > In spite of having explicit language covering this specification as an > 'experiment' the specification does not give me a clear and concrete > understanding of exactly what will be evaluated, or how, and what constitutes > satisfactory accomplishment. I'd let Scott illustrate Appendixes A1 and A2. They look quite clear to me. Best Ale -- From nobody Wed Mar 11 19:00:41 2020 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 B63ED3A1122 for ; Wed, 11 Mar 2020 19:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=gLUhcEGg; dkim=pass (2048-bit key) header.d=kitterman.com header.b=HR1gK8t6 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 FQQsrnE_0z98 for ; Wed, 11 Mar 2020 19:00:36 -0700 (PDT) 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 77C9D3A1121 for ; Wed, 11 Mar 2020 19:00:36 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 028BAF802AE for ; Wed, 11 Mar 2020 22:00:35 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1583978434; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Rg3ouXjsXLcsvBmF+/ta3FmU+kGuO/wwL58kCKfxMFQ=; b=gLUhcEGgq3MLEenVr7YsScekMVqvdZA5j08aWwsmHmjkZZPIVXKEXgVaKco4ZxYNnQJ6s XEXv7HFmuuIUF/hAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1583978434; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Rg3ouXjsXLcsvBmF+/ta3FmU+kGuO/wwL58kCKfxMFQ=; b=HR1gK8t6qEmqiH6e8OCY+wGzURet8BA2rhTbl1ZacWfw6CU2yfZ6ygVDVTSrBM5JYKAFD 25inJrIHrEMZule5DHa62t5zxuORnJJ6dhe/+28OkVdCBvCmRkIh7ZSgd114bYZOAgNg/Rb GlKSSlrVKZ2hiE12bUHut47oHpcwd4J3+itejF482fTwx+qiNKFFmQbXAEt4nr/kYmKsKeM 9p0Il/qzaxhcIGu5JvuLUblJgmosysKqr3g2ViQHQEzhq7ZSgXr/3BpDphpQe+63xKBoWfg 4/bKRv7QWue2/zwDSJ1YCgIpCUxJqolkof/WmNJL+peSASIeoVpDEq945cQA== Received: from l5580.localnet (unknown [24.248.18.5]) by interserver.kitterman.com (Postfix) with ESMTPSA id C6BA1F80218 for ; Wed, 11 Mar 2020 22:00:34 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 11 Mar 2020 22:00:32 -0400 Message-ID: <3996028.BDLCgmsoE7@l5580> In-Reply-To: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Thu, 12 Mar 2020 02:00:39 -0000 Comments in-line. Scott K On Tuesday, March 10, 2020 6:16:41 PM EDT Dave Crocker wrote: > This is offered as summary comments, focusing on some basic concerns, > rather than providing a detailed review of the specification. > > My original comments were posted 12 August 2019: > > https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg I have certainly reviewed those in detail. > 0. DMARC use of Organizational Domain > > DMARC specifies use of the Organizational Domain as a fallback for not > finding a DMARC record at the full domain name under scrutiny. The need > for this is to cover slow DMARC adoption among sub-domains and to handle > queries about non-existent domains. It also short circuits the need for a tree walk up to the organizational domain. I think it's also relevant to note that it only addresses queries about non-existent domains below the organizational domain level. This draft provides for an equivalent for non-existent organizational domains where appropriate. It also provides for a mechanism to express a different policy for non-existent and existent sub-domains. > 1. These are not 'public' suffixes (1) > > The concept of a 'public' suffix refers to domain names associated with > registries subject to externally-imposed operational policies. For want > of a better term, these operations are regulated. The domain suffixes > that PSD attends to are not public registries. > > * If the company that uses .example.com also gets .example, the > latter is not a 'public' domain. It is a private domain, just like > example.com. In terms of DMARC, the fact that it is delegated by ICANN > rather than a 'regular' registry is -- or at least should be -- irrelevant. > > * If member-based association that uses association.example gets > ..association, the latter is not a public domain. It's private. > > * A government-based domain name that want to enforce DMARC onto > subordinate domain names of subordinate agencies that haven't yet > adopted it are, of course, pursuing an entirely reasonable goal. But > these, too, are not public suffixes and their need is internal to their > organization. > > In every case, these are domains at the top of an administrative > authority, for all of the subordinate domains. That's the definition of > an Organizational Domain. That may be true as you have defined terms above, but it's not accurate relative to the current RFC 7489 definition, which is the relevant definition for this document. Additionally, the term public suffix as used in this document matches current common usage. In any case, the term public suffix is not baked into the protocol by this draft. If we want a different term if/when we fold this functionality into RFC 7489bis, we can use it. It's usage here won't constrain that decision. > > 2. Externalizing internal difficulties > > Some organizations have sub-groups to which various administrative > responsibilities have been delegated. In general, there can be many > levels of such delegation. Not just two. > > For the cases the PSD specification is intended to cover, > PSD seeks to adapt to slow DMARC adoption or non-existent domains for > one of its delegated sub-groups, by looking for an even-higher-level > encompassing record under a next-level Organizational Domain. That is, > PSD is specifying using two different Organizational Domains. The usual > one and its parent. > > A difficulty within the organization is being externalized to a burden > for everyone else on the net. Given the RFC 7489 definitions that are relevant for this draft, that's not correct. PSD is addressing non-organizational domains based on the current definitions. > > 3. DMARC wants the Organizational Domain > > The existing DMARC model is a) look under the full domain, and then b) > look under the Organizational Domain, as a fallback. My strong > suggestion is to keep the model as simple as that. > > The argument for adding just this one more layer of Organizational > Domain seems modest, primarily because it is purpose-built to handle a > new, special case, rather than because it represents a considered, > general case. > I don't think it just seems that way. No one has ever claimed that this PSD is generally appropriate for all domains. It's not. I translate your comment as 'because it is not useful for everyone, we shouldn't standardize it'. I don't think that's a reasonable approach. The IETF publishes documents all the time that have less than 100% applicability. That said, the applicability constraint for PSD is related to policy publishers. It is a generally useful addition for all receivers that check DMARC policy. > > 4. DMARC should not specify how to obtain the Organizational Domain. > > DMARC needs to say 'give me the organizational domain' or perhaps 'give > me the dmarc record under the organizational domain' and it needs to > have nothing to do with the method of satisfying the request. > > It's not that the problem being addressed by PSD isn't real. It's that > it needs to be viewed more carefully. > > The combination of this being a problem /within/ an organization, along > with the various continuing challenges of the PSL, mean that all > knowledge of this needs to be kept away from the DMARC spec. > This is unrelated to PSD. Your original objection was that PSD should not be published because of this unrelated issue. That did not generate (in my judgement) significant support withing the working group. It's presence in any discussion about PSD is a red herring. > > 5. There is little engagement with the PSD technical effort > > It is easy to see why owners of some domains would want a mechanism like > PSD. As noted, they do have a real and significant problem. So, > statements of support from such folk merely confirm their need. (As an > aside I'll note that historically the IETF hasn't been all that > interested in simplistic statements of support but, rather, actual > involvement in the engineering discussion.) > > What such statements do /not/ provide is any indication that the broader > Internet community has an interest in adopting this. > > First, where are the statements of actively engaged support from an > interesting set of organizations on the other side of these queries? In > general, there has been a track record of limited adoption for anything > that changes infrastructure services, in the absence of a very > widespread perception of need, benefit, and tractable operational cost. I don't think that accurately characterizes the situation for PSD. > Second, there has been a distinct lack of interest in the working > group's considering the concerns I've raised. Not none, just not much. > And the responses have mostly been to merely reject the concerns, such > as by asserting that an extra DNS query isn't expensive, ignoring the > architectural issues. Forgive my indulging in a small lack of modesty > in believing that I'm raising concerns that are relatively basic, having > some merit. I think you are confusing lack of agreement with lack of interest. I, for one, certainly paid close attention to them, but I remain unconvinced. I have no doubt your perspective is genuinely held and you wouldn't have raised them if you didn't believe they had merit, but I don't agree. > > > 6. The 'experiment' has vague goals and criteria > > In spite of having explicit language covering this specification as an > 'experiment' the specification does not give me a clear and concrete > understanding of exactly what will be evaluated, or how, and what > constitutes satisfactory accomplishment. > I won't argue it's clear, because I wouldn't have written it the way I did if I didn't think it was. It apparently seems to be reasonably straightforward to others based on WGLC and previous replies to your note. I'll leave it at that. > > I'm posting this primarily to finish an obligation and place it into the > working group record, rather than from an expectation that it will be > acted upon. Absent any indication of serious interest in serious and > constructive discussion, I won't be pressing this further, other than > possibly posting a pointer to it during IETF Last Call, as a formality. > Fair enough. I'm replying for essentially the same reasons. I don't expect you to agree, but I don't want it said no one paid attention. I certainly did. > d/ > > > > ----------------------------- > > > (1) The draft credits me for the term "public suffix". So I should > apologize, since it is now clear to me that these suffixes are very much > NOT public. They are private or governmental. From nobody Wed Mar 11 19:05:20 2020 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 85E7F3A1132 for ; Wed, 11 Mar 2020 19:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=/W2FgFZ3; dkim=pass (2048-bit key) header.d=kitterman.com header.b=fS1bCgxX 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 eoPaYXCR5Oeo for ; Wed, 11 Mar 2020 19:05:18 -0700 (PDT) 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 2AEEC3A112F for ; Wed, 11 Mar 2020 19:05:17 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id EBDA0F802AE for ; Wed, 11 Mar 2020 22:05:16 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1583978716; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=4XLC/24WFzoia/bzg37uAbPkVAEVnrZxLOogKJdBCUY=; b=/W2FgFZ3FX8lFHdTUpofd+lTjL/LxCMw9YRZNtyQmEmK1GmBGBTx/0aV91uD6bfROiT/k Uesl0rkc84IXX2RDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1583978716; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=4XLC/24WFzoia/bzg37uAbPkVAEVnrZxLOogKJdBCUY=; b=fS1bCgxX1t2KTHVPtrer34ttjQ1nPm0V839U+6pHXnqpJVSGPqxKJqX1tJ8boSy4AEF8o DbkREEZhxhNY/hYHlPnghaxMkCkD+vtajssRVqEMTVxOfxksv2u3vkz2lDBUVeyurB/VWyH 1kNCYwk22GyHQfJUqb2qPcCKm2YxJ0mGO7eIXpivldrzywtAX6XAk1Cw38Kewbm1kql7tds vq0gjX+TfivXhF331B0zYSFDQORE/CteGNeCduwwvS/39XkUwfevwzgo4Rnau9RocZN7qJm SnXaJ/uERTYIzmIRTZRRdVHu2Bt9MGiEnZwPA4ZQARxHgB44YTGbsHcp27iA== Received: from l5580.localnet (unknown [24.248.18.5]) by interserver.kitterman.com (Postfix) with ESMTPSA id BE71AF80218 for ; Wed, 11 Mar 2020 22:05:16 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 11 Mar 2020 22:05:15 -0400 Message-ID: <4811592.KVNcoShC6a@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Possible draft-ietf-dmarc-psd 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: Thu, 12 Mar 2020 02:05:20 -0000 If the chairs are up for it, I'd like to publish a revision to the draft that fixes the typo mentioned on the list two weeks ago and adds mil to the list of participating PSDs (they have published a record since the last draft update). I can also explicitly import organizational domain from RFC 7489 as recently discussed. Please let me know your preference. Scott K From nobody Wed Mar 11 20:37:09 2020 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 98E3D3A09CC for ; Wed, 11 Mar 2020 20:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JpotGxMS44lw for ; Wed, 11 Mar 2020 20:37:05 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 7CEE03A09B8 for ; Wed, 11 Mar 2020 20:37:05 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id u24so2793923vso.11 for ; Wed, 11 Mar 2020 20:37:05 -0700 (PDT) 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=l/u4fSVHYPHfL/sXLQE9JMJzec5hqtXbse8/pD9I+pI=; b=cng1E5mjzpV8snOLLy8naSHRwUgBZzT8XQRPWWC/ZxjwfjUkyCPw2jzrgsCHM2tRJu kuuTN9IwlNsA7QGL2agg9lIG5nJZM1mBdLen7rHnBrZjqhHEWLZYsnERuG1EgDVNGdnH qBWn6siCyQitdZMB6PNNGT/7nCPygQPUmvW2Fv18ovXdOXeI3gZYtXAbl8dRK8WycJSI fEFY5Rjg3L++eXyre22aL5Hp+YWdnxCxdHn1h/pF8cIX7mYr7aOrK/OnzTigMVIHl6Hm mnznHSoMwKwqGcXtRyZ2LF7uzmk2WLgAtVpUGNiWTgLIc4qVoJhCekBnn0b+NxNBDK8G Mthw== 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=l/u4fSVHYPHfL/sXLQE9JMJzec5hqtXbse8/pD9I+pI=; b=JGZ3IbZhwdr3ZnH2da1omV5jsedqkAak8GCx7mStqGTqVH5OPii9VmkCHp7BLstBif J2QqtOiecOK1uxZgENDLw1x+NPRSfIwgXHfubIoN/1zSdlcvKCcbRPwPYWeleqPcUVq4 80wbYASFHhmF1nAGwqGuD7KY738IwRR//B9+nDq2VQX3SsW/oBwGkNG+NS58ubFN/hj9 9GKBaPC61rBmt/04sVsYXnWoSFDELG54WaXP5Do9AE8fAwMcUvFhAOUr5D9NIGyuXpZT PJ+tBuT04HhQBIpNUgLBhRc9cBo6+IPCr0IV7RyNYb0TX/+axfOVabwjNAYDPGNkazOg dxWw== X-Gm-Message-State: ANhLgQ3OkiS4rWH/jF61VQiaEtrtb+gThFdMNGV31x6r/KSBUFVN+krr 4DXg6ADHsCGyla7w7xdcBet+D46ReLzSvj3z++V3wQ3D X-Google-Smtp-Source: ADFU+vt9EUbnYSwTrE1NeIHsoyGahPCLYONHEcgB06ormJ7YitaiLT48Ib6/1hOnpPxxbQCYTMf6W0Q4iyQJG5UXByY= X-Received: by 2002:a67:c898:: with SMTP id v24mr4105503vsk.13.1583984224331; Wed, 11 Mar 2020 20:37:04 -0700 (PDT) MIME-Version: 1.0 References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> <3996028.BDLCgmsoE7@l5580> In-Reply-To: <3996028.BDLCgmsoE7@l5580> From: "Murray S. Kucherawy" Date: Wed, 11 Mar 2020 20:36:53 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000056c1705a0a0115a" Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Thu, 12 Mar 2020 03:37:08 -0000 --000000000000056c1705a0a0115a Content-Type: text/plain; charset="UTF-8" As a participant: On Wed, Mar 11, 2020 at 7:00 PM Scott Kitterman wrote: > > 0. DMARC use of Organizational Domain > > > > DMARC specifies use of the Organizational Domain as a fallback for not > > finding a DMARC record at the full domain name under scrutiny. The need > > for this is to cover slow DMARC adoption among sub-domains and to handle > > queries about non-existent domains. > > It also short circuits the need for a tree walk up to the organizational > domain. I think it's also relevant to note that it only addresses queries > about non-existent domains below the organizational domain level. This > draft > provides for an equivalent for non-existent organizational domains where > appropriate. It also provides for a mechanism to express a different > policy > for non-existent and existent sub-domains. > Since we're mentioning a tree walk here, I believe we are ripe for a reopening of that debate. It's my understanding that the DNS community has softened its position on the impact of such a mechanism as a way of finding nodes of interest. I could be wrong, but there's one way to find out. Perhaps that is the case, and that a tree walk renders many of these issues moot. > 1. These are not 'public' suffixes (1) > > > > The concept of a 'public' suffix refers to domain names associated with > > registries subject to externally-imposed operational policies. For want > > of a better term, these operations are regulated. The domain suffixes > > that PSD attends to are not public registries. > > > I suspect the name used derives from the name of the resource to which DMARC attached itself early on, namely the Public Suffix List. Debating its name is probably out of scope here. And as Alessandro pointed out, the PSL was made for a different purpose and DMARC simply decide to use it to meet its own goals, which in turn supports DMARC distancing itself a bit. I believe where this is leading, though, is toward the notion that the use of the PSL should be considered external to DMARC. I don't think anyone has disagreed with that assertion. > 2. Externalizing internal difficulties > > > > Some organizations have sub-groups to which various administrative > > responsibilities have been delegated. In general, there can be many > > levels of such delegation. Not just two. > > > > For the cases the PSD specification is intended to cover, > > PSD seeks to adapt to slow DMARC adoption or non-existent domains for > > one of its delegated sub-groups, by looking for an even-higher-level > > encompassing record under a next-level Organizational Domain. That is, > > PSD is specifying using two different Organizational Domains. The usual > > one and its parent. > > > > A difficulty within the organization is being externalized to a burden > > for everyone else on the net. > Can you expand on how you see abuse of non-existent domains to be an exploitation of an internal problem? Specifically, what's the internal problem being exploited? > 5. There is little engagement with the PSD technical effort > > > > It is easy to see why owners of some domains would want a mechanism like > > PSD. As noted, they do have a real and significant problem. So, > > statements of support from such folk merely confirm their need. (As an > > aside I'll note that historically the IETF hasn't been all that > > interested in simplistic statements of support but, rather, actual > > involvement in the engineering discussion.) > > > > What such statements do /not/ provide is any indication that the broader > > Internet community has an interest in adopting this. > > > > First, where are the statements of actively engaged support from an > > interesting set of organizations on the other side of these queries? In > > general, there has been a track record of limited adoption for anything > > that changes infrastructure services, in the absence of a very > > widespread perception of need, benefit, and tractable operational cost. > > I don't think that accurately characterizes the situation for PSD. > I think there's some validity here at least in the claim that the purported interest has not made itself both visible and enthusiastic. Such dearth absolutely does not rise to the level of supporting something on the standards track, to be sure, but that wasn't the goal here either. > 6. The 'experiment' has vague goals and criteria > > > > In spite of having explicit language covering this specification as an > > 'experiment' the specification does not give me a clear and concrete > > understanding of exactly what will be evaluated, or how, and what > > constitutes satisfactory accomplishment. > As we're now under AD Evaluation and there's still an IETF Last Call to go, this is still on the table for being fixed if it appears by further reviewers to be unclear. -MSK --000000000000056c1705a0a0115a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a participant:

> 0. DMARC use of Organizational Domain
>
> DMARC specifies use of the Organizational Domain as a fallback for not=
> finding a DMARC record at the full domain name under scrutiny.=C2=A0 T= he need
> for this is to cover slow DMARC adoption among sub-domains and to hand= le
> queries about non-existent domains.

It also short circuits the need for a tree walk up to the organizational domain.=C2=A0 I think it's also relevant to note that it only addresses= queries
about non-existent domains below the organizational domain level.=C2=A0 Thi= s draft
provides for an equivalent for non-existent organizational domains where appropriate.=C2=A0 It also provides for a mechanism to express a different = policy
for non-existent and existent sub-domains.

<= div>Since we're mentioning a tree walk here, I believe we are ripe for = a reopening of that debate.=C2=A0 It's my understanding that the DNS co= mmunity has softened its position on the impact of such a mechanism as a wa= y of finding nodes of interest.=C2=A0 I could be wrong, but there's one= way to find out.=C2=A0 Perhaps that is the case, and that a tree walk rend= ers many of these issues moot.

> 1. These are not 'public' suffixes (1)
>
> The concept of a 'public' suffix refers to domain names associ= ated with
> registries subject to externally-imposed operational policies.=C2=A0 F= or want
> of a better term, these operations are regulated.=C2=A0 The domain suf= fixes
> that PSD attends to are not public registries.
>

I suspect the name used derives f= rom the name of the resource to which DMARC attached itself early on, namel= y the Public Suffix List.=C2=A0 Debating its name is probably out of scope = here.=C2=A0 And as Alessandro pointed out, the PSL was made for a different= purpose and DMARC simply decide to use it to meet its own goals, which in = turn supports DMARC distancing itself a bit.

I= believe where this is leading, though, is toward the notion that the use o= f the PSL should be considered external to DMARC.=C2=A0 I don't think a= nyone has disagreed with that assertion.

> 2. Externalizing internal difficul= ties
>
> Some organizations have sub-groups to which various administrative
> responsibilities have been delegated.=C2=A0 In general, there can be m= any
> levels of such delegation.=C2=A0 Not just two.
>
> For the cases the PSD specification is intended to cover,
> PSD seeks to adapt to slow DMARC adoption or non-existent domains for<= br> > one of its delegated sub-groups, by looking for an even-higher-level > encompassing record under a next-level Organizational Domain.=C2=A0 Th= at is,
> PSD is specifying using two different Organizational Domains.=C2=A0 Th= e usual
> one and its parent.
>
> A difficulty within the organization is being externalized to a burden=
> for everyone else on the net.

Can = you expand on how you see abuse of non-existent domains to be an exploitati= on of an internal problem?=C2=A0 Specifically, what's the internal prob= lem being exploited?

> 5. There is little engagement with the PSD techni= cal effort
>
> It is easy to see why owners of some domains would want a mechanism li= ke
> PSD.=C2=A0 As noted, they do have a real and significant problem.=C2= =A0 So,
> statements of support from such folk merely confirm their need.=C2=A0 = (As an
> aside I'll note that historically the IETF hasn't been all tha= t
> interested in simplistic statements of support but, rather, actual
> involvement in the engineering discussion.)
>
> What such statements do /not/ provide is any indication that the broad= er
> Internet community has an interest in adopting this.
>
> First, where are the statements of actively engaged support from an > interesting set of organizations on the other side of these queries?= =C2=A0 In
> general, there has been a track record of limited adoption for anythin= g
> that changes infrastructure services, in the absence of a very
> widespread perception of need, benefit, and tractable operational cost= .

I don't think that accurately characterizes the situation for PSD.=C2= =A0 =C2=A0

I think there's some val= idity here at least in the claim that the purported interest has not made i= tself both visible and enthusiastic.=C2=A0 Such dearth absolutely does not = rise to the level of supporting something on the standards track, to be sur= e, but that wasn't the goal here either.

> 6. The 'experiment'= ; has vague goals and criteria
>
> In spite of having explicit language covering this specification as an=
> 'experiment' the specification does not give me a clear and co= ncrete
> understanding of exactly what will be evaluated, or how, and what
> constitutes satisfactory accomplishment.

As we're now under AD Evaluation and there's still an IETF L= ast Call to go, this is still on the table for being fixed if it appears by= further reviewers to be unclear.=C2=A0

-MSK
--000000000000056c1705a0a0115a-- From nobody Wed Mar 11 20:37:38 2020 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 DF9893A09CE for ; Wed, 11 Mar 2020 20:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 APHayrqfCMBo for ; Wed, 11 Mar 2020 20:37:34 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 7C8D33A09CD for ; Wed, 11 Mar 2020 20:37:34 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id z125so2790721vsb.13 for ; Wed, 11 Mar 2020 20:37:34 -0700 (PDT) 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=zjB9Sx6SWkhWiXxUxn8A212/gVeEOHY/OlAABSCffCc=; b=jf13+DGZGZePj+PgnC9lcrHcmlkuSG+nrApgSs/JQVHOXPYT5SJoRVrgnK5ljxxfQ3 KbPM5uXMOosQANW5bBn+bY/YEfZL3iwatr29lqBLZADhB273Nm497Ips525OupeEfyJn +5qvmRvM2oHTTETNhsuTJhzYUvR6KLhi97PCSrfMv1SaMP9lJTv1yYrdZ9RH2U4hEBBw XKEjQfYhKyI5X7yJmKCz7CW7DXTJ50nFkTX6S7zePS5m2EKcCN30eoIkz92CodfFQiAo jfuvqZrsOKuGhEhEdW/zoZzfVtTNJ6EsCErlIUrZ+rdu/pWpVGCuZa4nlkFMbo73tlZh w2+A== 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=zjB9Sx6SWkhWiXxUxn8A212/gVeEOHY/OlAABSCffCc=; b=Tm18T77pHa1rJIdXlLT8gl+n+JSgMmCjJyAa/Sanu72aA3K7YFQnsmru7uFx8LD/Q/ Fiyc1LSafseufuG4sOWpLO/lzATVWGtVhUItGLgxHvNpWVmz3iHNvthD2MLTH8XGCUqW f9rub6AcDULilM9fHigYCxrqzcGlDtVqwYqcoU+t87ac7YX63T7ya477hP7DgmfsdzR1 FzOexDSEeoJKEM1kNHkLSnOEW7uTm6NePZghRR8jZBWjXahAHuspFAUovdVwsX/A+bZ5 Vo9HjahY6H9x46S6qIDwtyVDkU0CZfrPNWZ8ouLTOO7enpjiC1kNwYKLW+/d32x5G4J+ cV5g== X-Gm-Message-State: ANhLgQ0SHbH7eMoOZHpDVXreVLdnrdSjTK+KUWIPafXe+9cemyTGsMuM clLSJijCrKWVeaFkK+F5YGrREUoJmlTpu5KxzTWdGQ7J X-Google-Smtp-Source: ADFU+vta4FIIsRey4RWBurHtIKkgHplziqnJWl+D7lRnzPS07RclRUxnoBaEkJR1cZqQDIOvH/U46l1xIfbRUxQxk3I= X-Received: by 2002:a67:800b:: with SMTP id b11mr4248276vsd.175.1583984253412; Wed, 11 Mar 2020 20:37:33 -0700 (PDT) MIME-Version: 1.0 References: <4811592.KVNcoShC6a@l5580> In-Reply-To: <4811592.KVNcoShC6a@l5580> From: "Murray S. Kucherawy" Date: Wed, 11 Mar 2020 20:37:21 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="000000000000c1289a05a0a012d9" Archived-At: Subject: Re: [dmarc-ietf] Possible draft-ietf-dmarc-psd 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: Thu, 12 Mar 2020 03:37:36 -0000 --000000000000c1289a05a0a012d9 Content-Type: text/plain; charset="UTF-8" As we're in AD Review now, I'll let Alexey decide. On Wed, Mar 11, 2020 at 7:05 PM Scott Kitterman wrote: > If the chairs are up for it, I'd like to publish a revision to the draft > that > fixes the typo mentioned on the list two weeks ago and adds mil to the > list of > participating PSDs (they have published a record since the last draft > update). > I can also explicitly import organizational domain from RFC 7489 as > recently > discussed. > > Please let me know your preference. > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000c1289a05a0a012d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As we're in AD Review now, I'll let Alexey decide.=

On Wed, Mar 11, 2020 at 7:05 PM Scott Kitterman <sklist@kitterman.com> wrote:
If the chairs are up for it, I'= ;d like to publish a revision to the draft that
fixes the typo mentioned on the list two weeks ago and adds mil to the list= of
participating PSDs (they have published a record since the last draft updat= e).=C2=A0
I can also explicitly import organizational domain from RFC 7489 as recentl= y
discussed.

Please let me know your preference.

Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000c1289a05a0a012d9-- From nobody Thu Mar 12 01:43:48 2020 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 16DCE3A135E for ; Thu, 12 Mar 2020 01:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: 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 hvd4anr39V03 for ; Thu, 12 Mar 2020 01:43:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 ADD4D3A135D for ; Thu, 12 Mar 2020 01:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1584002621; bh=LkP9Q28N0ophte2aCVRoxuZL53YjAqYRhaHQZgGRHcw=; l=1381; h=To:References:From:Date:In-Reply-To; b=BVoGA4ck4g0a3i2/J1ORnpMxUytyLT0LfEh2gwKsZfY7eROy+HVuKoe847MfSMhHj +oz4/xGOTBT7ekFgVovUYqEkBbb7Blhal1fVuZu1eMAb+oat+ivsU7bQh8ah92LZCW hTINisFaHrm5hnWuDXyiRHPlPjeQAKWrSDot7uJonIxAp0rakeQ94S4j+9Ri3 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02F.000000005E69F63D.00005752; Thu, 12 Mar 2020 09:43:41 +0100 To: dmarc@ietf.org References: <4811592.KVNcoShC6a@l5580> From: Alessandro Vesely Message-ID: <8f1487b8-3218-39d7-360c-11d1dfea5f43@tana.it> Date: Thu, 12 Mar 2020 09:43:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <4811592.KVNcoShC6a@l5580> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Possible draft-ietf-dmarc-psd 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: Thu, 12 Mar 2020 08:43:46 -0000 On Thu 12/Mar/2020 03:05:15 +0100 Scott Kitterman wrote: > If the chairs are up for it, I'd like to publish a revision to the draft that > fixes the typo mentioned on the list two weeks ago and adds mil to the list of > participating PSDs (they have published a record since the last draft update). Hey, that's true: ale@pcale:~ dig _dmarc.mil txt ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 15461 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 6; ADDITIONAL: 6 ;; QUESTION SECTION: ;; _dmarc.mil. IN TXT ;; ANSWER SECTION: _dmarc.MIL. 21600 IN TXT "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_reports@mail.mil" ;; AUTHORITY SECTION: mil. 172800 IN NS pac1.nipr.mil. mil. 172800 IN NS eur2.nipr.mil. mil. 172800 IN NS con1.nipr.mil. mil. 172800 IN NS pac2.nipr.mil. mil. 172800 IN NS eur1.nipr.mil. mil. 172800 IN NS con2.nipr.mil. ;; ADDITIONAL SECTION: con1.nipr.mil. 172800 IN A 199.252.157.234 con2.nipr.mil. 172800 IN A 199.252.162.234 eur1.nipr.mil. 172800 IN A 199.252.154.234 eur2.nipr.mil. 172800 IN A 199.252.143.234 pac1.nipr.mil. 172800 IN A 199.252.180.234 pac2.nipr.mil. 172800 IN A 199.252.155.234 If they can do it, _dmarc.bank should be publishable as well, shouldn't it? > I can also explicitly import organizational domain from RFC 7489 as recently > discussed. +1 Best Ale -- From nobody Thu Mar 12 03:54:08 2020 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 6B57C3A0B63 for ; Thu, 12 Mar 2020 03:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=Lk1xTf8I; dkim=pass (2048-bit key) header.d=kitterman.com header.b=m/Ki9QHr 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 J8J38K-Gpn3X for ; Thu, 12 Mar 2020 03:54:05 -0700 (PDT) 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 DC5783A0B40 for ; Thu, 12 Mar 2020 03:54:01 -0700 (PDT) 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 8DA13F80271 for ; Thu, 12 Mar 2020 06:54:00 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1584010440; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=7gOF28mPQKgptsMEAMjE5stsxYDQHl3jrYyP6bnJYnU=; b=Lk1xTf8IwZGN6Y4yJgPlLWIWkOlhuKwFvdI8EcCHvIjoNzff2+KLKlSEWD+aK6YZH/9oz +38Fa0h0jBJcFNqBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1584010440; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=7gOF28mPQKgptsMEAMjE5stsxYDQHl3jrYyP6bnJYnU=; b=m/Ki9QHrfNbXQ2IV8226o0v1sQ3yJp3hjFojuBKIXxXjoCJgZT4nRAcL8coFS/j/Fmp02 eaFCcUpibTEMlhd+u9n8+xuXvYoj/z5id4cjsPi2EVYUPjymFpj/vO3xuQ3igX0vmgIN9av OSA/8LyrCsvMtgsX4ibIxXjwfGQSxHeKapM5PH+TvaljTtAyHimXgJsrPQZNv3ShqfFlLZz XwgRlCDTOqAAmX8beCapXZv/jDJz3z0PAGFs7CHidvCMZ1LKDs8OekIiRiaITm39y3/+YW3 nujCWuOY9riw7JTDK05hbJbCQKKbAySgOcH3KYz18RGHMORGMxfSwXuQeD9A== Received: from l5580.localnet (unknown [24.248.18.5]) by interserver.kitterman.com (Postfix) with ESMTPSA id 48426F80223 for ; Thu, 12 Mar 2020 06:54:00 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 12 Mar 2020 06:53:59 -0400 Message-ID: <5253915.xZbvQRboAD@l5580> In-Reply-To: <8f1487b8-3218-39d7-360c-11d1dfea5f43@tana.it> References: <4811592.KVNcoShC6a@l5580> <8f1487b8-3218-39d7-360c-11d1dfea5f43@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Possible draft-ietf-dmarc-psd 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: Thu, 12 Mar 2020 10:54:07 -0000 On Thursday, March 12, 2020 4:43:41 AM EDT Alessandro Vesely wrote: > On Thu 12/Mar/2020 03:05:15 +0100 Scott Kitterman wrote: > > If the chairs are up for it, I'd like to publish a revision to the draft > > that fixes the typo mentioned on the list two weeks ago and adds mil to > > the list of participating PSDs (they have published a record since the > > last draft update). > Hey, that's true: ... > If they can do it, _dmarc.bank should be publishable as well, shouldn't it? No. Different rules apply to .mil and .gov. Scott K From nobody Thu Mar 12 04:05:24 2020 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 705C43A0D2D for ; Thu, 12 Mar 2020 04:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=fastmail.fm header.b=EYKlBPEr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZcyHt6BO 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 OkL4e8Rkm_53 for ; Thu, 12 Mar 2020 04:05:12 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84C13A0D33 for ; Thu, 12 Mar 2020 04:05:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 04AD1904; Thu, 12 Mar 2020 07:05:11 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Thu, 12 Mar 2020 07:05:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=yZqaDGiPwQEOy5SUndh3bnxzLV5ZWuM PFr/3xISb80k=; b=EYKlBPEr/j3OHrdcY27oydl0D/KqdUZ5979nhL8QPj6GccN Wo3puKvfue/OBA4xZnnsXro4bN/RQ+M9iMz3HYpfXVcLtRq/1KepsQaWjNbZ/NAQ iBbeE/FKbwXqNo96mKSYQGYcdojbROFpdb2vq/RNADnwdLoyaC3oPDKj3c/+gLam sxOA/0kdnaEtKNr3PXQEeiRMSe9RwS2guEDdpETVoXB1ne1Cdwo4n9r3U2iZw6Yc fENSCQ/o79n3DEmsPsKglsB3z9tDjHG3V6Qzo4JXzq3MxHRzGVfarXXMAuRlPV9Z bNwcRiFqaDxeI9OjQ9KKgtkB+keUpodT1uIhB9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yZqaDG iPwQEOy5SUndh3bnxzLV5ZWuMPFr/3xISb80k=; b=ZcyHt6BOFGZFnTXqnbQmUe BMcrWvPHvO6d1rPViKi6Gy8B3AZPdH+Z50+sXImOfcAX1c6U12liD2eqRTPFQfWb MwG4IYDALnNhZ0bXfaH6YWTRb42EBt0EPIo0LN6rckDQbbIcSVvHwxEaofbmbINx vYK5PVybhdh3XyA6/aKWmVQmvIn/YP2lflvW18eY+vShI1rQOIF+wa4mSDHlt+mh dOlro8Slb6O0KUdXc6uUrvJRSvgAN/RTuSfkiNGv5VpnGtLOGpzlbwfR9TM96n5u AYmPpt+ZKAnaCV9lcu+3r9MBvT1LaCm+Jfbj1KhhCXnloWQ/r1kAeH9Yw6lbS6wA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvhedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrih hlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3AE81660069; Thu, 12 Mar 2020 07:05:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <58f3b95d-907e-4940-abec-fc2ea34aa806@www.fastmail.com> In-Reply-To: References: <4811592.KVNcoShC6a@l5580> Date: Thu, 12 Mar 2020 11:04:29 +0000 From: "Alexey Melnikov" To: "Murray S. Kucherawy" , "Scott Kitterman" Cc: "IETF DMARC WG" Content-Type: multipart/alternative; boundary=bba79a792ede4728941efc31107c362d Archived-At: Subject: Re: [dmarc-ietf] Possible draft-ietf-dmarc-psd 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: Thu, 12 Mar 2020 11:05:23 -0000 --bba79a792ede4728941efc31107c362d Content-Type: text/plain On Thu, Mar 12, 2020, at 3:37 AM, Murray S. Kucherawy wrote: > As we're in AD Review now, I'll let Alexey decide. Please do a new revision. I will be able to cope. > > On Wed, Mar 11, 2020 at 7:05 PM Scott Kitterman wrote: >> If the chairs are up for it, I'd like to publish a revision to the draft that >> fixes the typo mentioned on the list two weeks ago and adds mil to the list of >> participating PSDs (they have published a record since the last draft update). >> I can also explicitly import organizational domain from RFC 7489 as recently >> discussed. >> >> Please let me know your preference. >> >> Scott K >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc --bba79a792ede4728941efc31107c362d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12,= 2020, at 3:37 AM, Murray S. Kucherawy wrote:
As we're in AD Review now, I'll let Al= exey decide.
Please do a new revision. I will= be able to cope.


On Wed, Mar 11, 2020 at 7:05 PM Scott Kitterman <<= a href=3D"mailto:sklist@kitterman.com">sklist@kitterman.com> wrot= e:
If the chairs are up for it, I'd like to publish a revi= sion to the draft that
fixes the typo mentioned on the l= ist two weeks ago and adds mil to the list of
participat= ing PSDs (they have published a record since the last draft update).&nbs= p;
I can also explicitly import organizational domain fr= om RFC 7489 as recently
discussed.

Please let me know your preference.

<= div> Scott K


____________= ___________________________________
dmarc mailing list
--bba79a792ede4728941efc31107c362d-- From nobody Thu Mar 12 05:10:40 2020 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 994C53A0EC3; Thu, 12 Mar 2020 05:10:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <158401503452.18129.15215096815262616454@ietfa.amsl.com> Date: Thu, 12 Mar 2020 05:10:34 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-08.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 12 Mar 2020 12:10:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-08.txt Pages : 15 Date : 2020-03-12 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. Domains at which registrations can occur are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. This document also seeks to address implementations that consider a domain on a public Suffix list to be ineligible for DMARC enforcement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-08 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 12 05:11:21 2020 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 3B6883A0FC3 for ; Thu, 12 Mar 2020 05:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=uSqKdZ3E; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Nj4894gg 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 OTOLdvDda4zU for ; Thu, 12 Mar 2020 05:11:11 -0700 (PDT) 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 84E103A0EE1 for ; Thu, 12 Mar 2020 05:11:10 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 6C02EF80271 for ; Thu, 12 Mar 2020 08:11:09 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1584015069; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ZOvMrH/Pr9xwnC/0WDNDVAXv1O7Zu0xwfDUHqCQ58qc=; b=uSqKdZ3El/FcfP9xiKRD6vU/bNdpZxpO7IhIcRHAe66oakVpai3QvsGvFGOJd0cbOdz3+ weP1JHeDU8oVPbaCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1584015069; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ZOvMrH/Pr9xwnC/0WDNDVAXv1O7Zu0xwfDUHqCQ58qc=; b=Nj4894gg8KQ3wMCm3Ftoj3P8uHqDqlvDzPqhdq5+C8BGONUvPDwEI0ZtRg6pPEQYattrb P5BkXWCqDgDLxWNjsJ0LDc5TFvr1w6U6BWAPBeHW4L8btfr4EQs+oJRPkB/9DlXhV2kcjAh 8hsXsAlhu1zk3hzB9jV+7uTpFoEFny4obKh8eszWm4+A5h0WndEfxOyDNOmxAFxUTvCQ2jv J22Z8xLXyX7ZHh7ruQNFD/YO8ZjQQa5uEPb7B2DiJse0BcMZJgM2gHqoqKql5vwSy9xDTG7 pccKGMPBPPFHPruo3OjXl6Zt4H5RYXUCs46Z2p8wlCRS2SedNQmwKmI7LPpg== Received: from l5580.localnet (unknown [24.248.18.5]) by interserver.kitterman.com (Postfix) with ESMTPSA id 4175DF80223 for ; Thu, 12 Mar 2020 08:11:09 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 12 Mar 2020 08:11:07 -0400 Message-ID: <1686551.N7XYENQPcq@l5580> In-Reply-To: <58f3b95d-907e-4940-abec-fc2ea34aa806@www.fastmail.com> References: <4811592.KVNcoShC6a@l5580> <58f3b95d-907e-4940-abec-fc2ea34aa806@www.fastmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Possible draft-ietf-dmarc-psd 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: Thu, 12 Mar 2020 12:11:19 -0000 On Thursday, March 12, 2020 7:04:29 AM EDT Alexey Melnikov wrote: > On Thu, Mar 12, 2020, at 3:37 AM, Murray S. Kucherawy wrote: > > As we're in AD Review now, I'll let Alexey decide. > > Please do a new revision. I will be able to cope. > Thanks, Done. Scott K From nobody Sun Mar 15 05:49:39 2020 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 9A6413A15A6 for ; Sun, 15 Mar 2020 05:49:37 -0700 (PDT) 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, 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 G-C_kHsyW-h4 for ; Sun, 15 Mar 2020 05:49:34 -0700 (PDT) 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 BC0123A15A7 for ; Sun, 15 Mar 2020 05:49:34 -0700 (PDT) Received: from [192.168.1.67] (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 02FCp1L5024970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 15 Mar 2020 05:51:01 -0700 From: Dave Crocker Reply-To: dcrocker@bbiw.net References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> <856481e5-7497-ba81-fb1f-dba2b645276c@tana.it> To: IETF DMARC WG Organization: Brandenburg InternetWorking Message-ID: <378e83ae-f326-695c-a3c2-d0e099fd97b4@dcrocker.net> Date: Sun, 15 Mar 2020 05:49:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <856481e5-7497-ba81-fb1f-dba2b645276c@tana.it> Content-Type: multipart/alternative; boundary="------------CD1259FD2C2BF79DA8D4A50A" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Sun, 15 Mar 2020 12:49:38 -0000 This is a multi-part message in MIME format. --------------CD1259FD2C2BF79DA8D4A50A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/11/2020 10:08 AM, Alessandro Vesely wrote: >> 1. These are not 'public' suffixes (1) The concept of a 'public' >> suffix refers to domain names associated with registries subject to >> externally-imposed operational policies.  For want of a better term, >> these operations are regulated.  The domain suffixes that PSD attends >> to are not public registries. > ... For "public suffix", I propose we stick to the definition referred > by rfc8499. OK, let's do that:      "Public suffix: "A domain that is controlled by a public registry." I gave three examples of types of domains, like the owner of example.com getting .example.  In each of those 3 cases, these domain names are not controlled by a public registry.  So they are not "public suffix domains". >> 3. DMARC wants the Organizational Domain The existing DMARC model is >> a) look under the full domain, and then b) look under the >> Organizational Domain, as a fallback.  My strong suggestion is to >> keep the model as simple as that. The argument for adding just this >> one more layer of Organizational Domain seems modest, primarily >> because it is purpose-built to handle a new, special case, rather >> than because it represents a considered, general case. > Having three levels instead of two sounds quite general. That's nice.  And there is a common computer science view that it can be.  But in this case it isn't true.  Rather, it is a very specialized, purpose-built addendum.  There is nothing general about it at all. On 3/11/2020 7:00 PM, Scott Kitterman wrote: >> 0. DMARC use of Organizational Domain DMARC specifies use of the >> Organizational Domain as a fallback for not finding a DMARC record at >> the full domain name under scrutiny. The need for this is to cover >> slow DMARC adoption among sub-domains and to handle queries about >> non-existent domains. > > It also short circuits the need for a tree walk up to the > organizational domain. I think it's also relevant to note that it only > addresses queries about non-existent domains below the organizational > domain level. Oh? Perhaps I've mis-remembered or misread my review of the text, but it also covers existing domains that do not have a dmarc record. >> 1. These are not 'public' suffixes (1) The concept of a 'public' >> suffix refers to domain names associated with registries subject to >> externally-imposed operational policies. For want of a better term, >> these operations are regulated. The domain suffixes that PSD attends >> to are not public registries. * If the company that uses .example.com >> also gets .example, the latter is not a 'public' domain. It is a >> private domain, just like example.com. In terms of DMARC, the fact >> that it is delegated by ICANN rather than a 'regular' registry is -- >> or at least should be -- irrelevant. * If member-based association >> that uses association.example gets ..association, the latter is not a >> public domain. It's private. * A government-based domain name that >> want to enforce DMARC onto subordinate domain names of subordinate >> agencies that haven't yet adopted it are, of course, pursuing an >> entirely reasonable goal. But these, too, are not public suffixes and >> their need is internal to their organization. In every case, these >> are domains at the top of an administrative authority, for all of the >> subordinate domains. That's the definition of an Organizational Domain. > > That may be true as you have defined terms above, but it's not > accurate relative to the current RFC 7489 definition, which is the > relevant definition for this document. Which definition are you referring to?  The one cited in RFC 8499, referenced above? Or the one in  RFC 7489 (Section 3.2) which simply says "a list of DNS domain names reserved for registrations"? I don't really know what 'reserved for registrations" means, but it does not seem to cover the domain names of interest to this draft. >> 2. Externalizing internal difficulties Some organizations have >> sub-groups to which various administrative responsibilities have been >> delegated. In general, there can be many levels of such delegation. >> Not just two. For the cases the PSD specification is intended to >> cover, PSD seeks to adapt to slow DMARC adoption or non-existent >> domains for one of its delegated sub-groups, by looking for an >> even-higher-level encompassing record under a next-level >> Organizational Domain. That is, PSD is specifying using two different >> Organizational Domains. The usual one and its parent. A difficulty >> within the organization is being externalized to a burden for >> everyone else on the net. > > Given the RFC 7489 definitions that are relevant for this draft, > that's not correct. PSD is addressing non-organizational domains based > on the current definitions. Apparently the nature of the 'internal' issue I mean wasn't clear.  I'll try to clarify: The organization that controls this bit of hierarchy controls the domain name the PSD draft is seeking to identify and use.  It also controls the one below it that is otherwise viewed as the organizational domain.  For some organizations, there will be other administrative boundaries, below this, for subordinate companies or departments, or the like. For large, complex organizations, there can be an extensive administrative hierarchy and it might be reflected in a large, complex domain name hierarchy. The organization has two internal problems here.  One is that the top of the organizational hierarchy is not getting identified properly through whatever 'public suffix' list it is based on. The other is that it has inadequate control over the domains that /are/ getting identified.  If it had adequate control, those subordinate domain names would have DMARC records. The burden for dealing with these failures is being placed on receivers, outside of the organization. >> 3. DMARC wants the Organizational Domain The existing DMARC model is >> a) look under the full domain, and then b) look under the >> Organizational Domain, as a fallback. My strong suggestion is to keep >> the model as simple as that. The argument for adding just this one >> more layer of Organizational Domain seems modest, primarily because >> it is purpose-built to handle a new, special case, rather than >> because it represents a considered, general case. > > I don't think it just seems that way. No one has ever claimed that > this PSD is generally appropriate for all domains. It's not. I > translate your comment as 'because it is not useful for everyone, we > shouldn't standardize it'. I don't think that's a reasonable approach. > The IETF publishes documents all the time that have less than 100% > applicability. That said, the applicability constraint for PSD is > related to policy publishers. It is a generally useful addition for > all receivers that check DMARC policy. First, yes, Internet standards are typically expected to scale.  And they typically seek widespread adoption. For PSD, please consider who has to implement this, for it to be useful.  Try describing this in some detail, both for domain owners and filtering receivers. The latter is the more interesting set, since they need added code and execution. To be useful, a mechanism like this needs very widespread adoption. >> 4. DMARC should not specify how to obtain the Organizational Domain. >> DMARC needs to say 'give me the organizational domain' or perhaps >> 'give me the dmarc record under the organizational domain' and it >> needs to have nothing to do with the method of satisfying the >> request. It's not that the problem being addressed by PSD isn't real. >> It's that it needs to be viewed more carefully. The combination of >> this being a problem /within/ an organization, along with the various >> continuing challenges of the PSL, mean that all knowledge of this >> needs to be kept away from the DMARC spec. > > This is unrelated to PSD. Your original objection was that PSD should > not be published because of this unrelated issue. That did not > generate (in my judgement) significant support withing the working > group. It's presence in any discussion about PSD is a red herring. Please explain with some substance.  That is, what is the basis for your conclusion? >> 5. There is little engagement with the PSD technical effort It is >> easy to see why owners of some domains would want a mechanism like >> PSD. As noted, they do have a real and significant problem. So, >> statements of support from such folk merely confirm their need. (As >> an aside I'll note that historically the IETF hasn't been all that >> interested in simplistic statements of support but, rather, actual >> involvement in the engineering discussion.) What such statements do >> /not/ provide is any indication that the broader Internet community >> has an interest in adopting this. First, where are the statements of >> actively engaged support from an interesting set of organizations on >> the other side of these queries? In general, there has been a track >> record of limited adoption for anything that changes infrastructure >> services, in the absence of a very widespread perception of need, >> benefit, and tractable operational cost. > > I don't think that accurately characterizes the situation for PSD. That's nice.  Please point to the record of active engagement by both domain owners and those who must implement and run filtering receivers, for this mechanism to be effective. > On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote: >> Since we're mentioning a tree walk here, I believe we are ripe for a >> reopening of that debate. That's a shame. Besides created additional general cost, it creates an attack vector. Consider: From foo@bogus.bogus.bogus.bogus.bogus...bogus.bogus.example.com >> > 1. These are not 'public' suffixes (1) >> > >> > The concept of a 'public' suffix refers to domain names >> associated with >> > registries subject to externally-imposed operational policies.  >> For want >> > of a better term, these operations are regulated.  The domain >> suffixes >> > that PSD attends to are not public registries. >> > >> >> >> I suspect the name used derives from the name of the resource to >> which DMARC attached itself early on, namely the Public Suffix List.  >> Debating its name is probably out of scope here. It's not, because the term facilitates a basic misunderstanding about the nature of the domain names involved here.  That's why I am raising a concern about the term's use. >> And as Alessandro pointed out, the PSL was made for a different >> purpose and DMARC simply decide to use it to meet its own goals, >> which in turn supports DMARC distancing itself a bit. >> >> I believe where this is leading, though, is toward the notion that >> the use of the PSL should be considered external to DMARC.  I don't >> think anyone has disagreed with that assertion. And yet both DMARC and PSD have text tied to the term and its function. >> >> > 2. Externalizing internal difficulties >> > >> > Some organizations have sub-groups to which various administrative >> > responsibilities have been delegated.  In general, there can be >> many >> > levels of such delegation.  Not just two. >> > >> > For the cases the PSD specification is intended to cover, >> > PSD seeks to adapt to slow DMARC adoption or non-existent >> domains for >> > one of its delegated sub-groups, by looking for an >> even-higher-level >> > encompassing record under a next-level Organizational Domain.  >> That is, >> > PSD is specifying using two different Organizational Domains.  >> The usual >> > one and its parent. >> > >> > A difficulty within the organization is being externalized to a >> burden >> > for everyone else on the net. >> >> >> Can you expand on how you see abuse of non-existent domains to be an >> exploitation of an internal problem? Specifically, what's the >> internal problem being exploited? I apologize for not being more clear about what I meant.  I hope that the above effort elaborate on this suffices. Basically it concerns an organization's inability to get its subordinates to publish DMARC records and problems with PSLs that lead to identifying the wrong domain as an OD.  Or somesuch... >> >> > 5. There is little engagement with the PSD technical effort >> > >> > It is easy to see why owners of some domains would want a >> mechanism like >> > PSD.  As noted, they do have a real and significant problem.  So, >> > statements of support from such folk merely confirm their >> need.  (As an >> > aside I'll note that historically the IETF hasn't been all that >> > interested in simplistic statements of support but, rather, actual >> > involvement in the engineering discussion.) >> > >> > What such statements do /not/ provide is any indication that >> the broader >> > Internet community has an interest in adopting this. >> > >> > First, where are the statements of actively engaged support from an >> > interesting set of organizations on the other side of these >> queries?  In >> > general, there has been a track record of limited adoption for >> anything >> > that changes infrastructure services, in the absence of a very >> > widespread perception of need, benefit, and tractable >> operational cost.. >> >> I don't think that accurately characterizes the situation for PSD. >> >> >> I think there's some validity here at least in the claim that the >> purported interest has not made itself both visible and >> enthusiastic.  Such dearth absolutely does not rise to the level of >> supporting something on the standards track, to be sure, but that >> wasn't the goal here either. Heh.  An IETF-approved 'experiment' is not a casual activity. A lack of a substantial and wide base of support normally has been significant, even for an IETF-track experimental RFC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------CD1259FD2C2BF79DA8D4A50A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/11/2020 10:08 AM, Alessandro Vesely wrote:
1. These are not 'public' suffixes (1) The concept of a 'public' suffix refers to domain names associated with registries subject to externally-imposed operational policies.  For want of a better term, these operations are regulated.  The domain suffixes that PSD attends to are not public registries.
... For "public suffix", I propose we stick to the definition referred by rfc8499.


OK, let's do that:

     "Public suffix: "A domain that is controlled by a public registry."


I gave three examples of types of domains, like the owner of example.com getting .example.  In each of those 3 cases, these domain names are not controlled by a public registry.  So they are not "public suffix domains".
3. DMARC wants the Organizational Domain The existing DMARC model is a) look under the full domain, and then b) look under the Organizational Domain, as a fallback.  My strong suggestion is to keep the model as simple as that. The argument for adding just this one more layer of Organizational Domain seems modest, primarily because it is purpose-built to handle a new, special case, rather than because it represents a considered, general case.
Having three levels instead of two sounds quite general.


That's nice.  And there is a common computer science view that it can be.  But in this case it isn't true.  Rather, it is a very specialized, purpose-built addendum.  There is nothing general about it at all.



On 3/11/2020 7:00 PM, Scott Kitterman wrote:
0. DMARC use of Organizational Domain DMARC specifies use of the Organizational Domain as a fallback for not finding a DMARC record at the full domain name under scrutiny. The need for this is to cover slow DMARC adoption among sub-domains and to handle queries about non-existent domains.

It also short circuits the need for a tree walk up to the organizational domain. I think it's also relevant to note that it only addresses queries about non-existent domains below the organizational domain level.


Oh? Perhaps I've mis-remembered or misread my review of the text, but it also covers existing domains that do not have a dmarc record.



1. These are not 'public' suffixes (1) The concept of a 'public' suffix refers to domain names associated with registries subject to externally-imposed operational policies. For want of a better term, these operations are regulated. The domain suffixes that PSD attends to are not public registries. * If the company that uses .example.com also gets .example, the latter is not a 'public' domain. It is a private domain, just like example.com. In terms of DMARC, the fact that it is delegated by ICANN rather than a 'regular' registry is -- or at least should be -- irrelevant. * If member-based association that uses association.example gets ..association, the latter is not a public domain. It's private. * A government-based domain name that want to enforce DMARC onto subordinate domain names of subordinate agencies that haven't yet adopted it are, of course, pursuing an entirely reasonable goal. But these, too, are not public suffixes and their need is internal to their organization. In every case, these are domains at the top of an administrative authority, for all of the subordinate domains. That's the definition of an Organizational Domain.

That may be true as you have defined terms above, but it's not accurate relative to the current RFC 7489 definition, which is the relevant definition for this document.


Which definition are you referring to?  The one cited in RFC 8499, referenced above? Or the one in  RFC 7489 (Section 3.2)  which simply says "a list of DNS domain names reserved for registrations"?

I don't really know what 'reserved for registrations" means, but it does not seem to cover the domain names of interest to this draft.


2. Externalizing internal difficulties Some organizations have sub-groups to which various administrative responsibilities have been delegated. In general, there can be many levels of such delegation. Not just two. For the cases the PSD specification is intended to cover, PSD seeks to adapt to slow DMARC adoption or non-existent domains for one of its delegated sub-groups, by looking for an even-higher-level encompassing record under a next-level Organizational Domain. That is, PSD is specifying using two different Organizational Domains. The usual one and its parent. A difficulty within the organization is being externalized to a burden for everyone else on the net.

Given the RFC 7489 definitions that are relevant for this draft, that's not correct. PSD is addressing non-organizational domains based on the current definitions.


Apparently the nature of the 'internal' issue I mean wasn't clear.  I'll try to clarify:

The organization that controls this bit of hierarchy controls the domain name the PSD draft is seeking to identify and use.  It also controls the one below it that is otherwise viewed as the organizational domain.  For some organizations, there will be other administrative boundaries, below this, for subordinate companies or departments, or the like. For large, complex organizations, there can be an extensive administrative hierarchy and it might be reflected in a large, complex domain name hierarchy.

The organization has two internal problems here.  One is that the top of the organizational hierarchy is not getting identified properly through whatever 'public suffix' list it is based on. The other is that it has inadequate control over the domains that /are/ getting identified.  If it had adequate control, those subordinate domain names would have DMARC records.


The burden for dealing with these failures is being placed on receivers, outside of the organization.
 

3. DMARC wants the Organizational Domain The existing DMARC model is a) look under the full domain, and then b) look under the Organizational Domain, as a fallback. My strong suggestion is to keep the model as simple as that. The argument for adding just this one more layer of Organizational Domain seems modest, primarily because it is purpose-built to handle a new, special case, rather than because it represents a considered, general case.

I don't think it just seems that way. No one has ever claimed that this PSD is generally appropriate for all domains. It's not. I translate your comment as 'because it is not useful for everyone, we shouldn't standardize it'. I don't think that's a reasonable approach. The IETF publishes documents all the time that have less than 100% applicability. That said, the applicability constraint for PSD is related to policy publishers. It is a generally useful addition for all receivers that check DMARC policy.


First, yes, Internet standards are typically expected to scale.  And they typically seek widespread adoption.


For PSD, please consider who has to implement this, for it to be useful.  Try describing this in some detail, both for domain owners and filtering receivers.


The latter is the more interesting set, since they need added code and execution.


To be useful, a mechanism like this needs very widespread adoption.


4. DMARC should not specify how to obtain the Organizational Domain. DMARC needs to say 'give me the organizational domain' or perhaps 'give me the dmarc record under the organizational domain' and it needs to have nothing to do with the method of satisfying the request. It's not that the problem being addressed by PSD isn't real. It's that it needs to be viewed more carefully. The combination of this being a problem /within/ an organization, along with the various continuing challenges of the PSL, mean that all knowledge of this needs to be kept away from the DMARC spec.

This is unrelated to PSD. Your original objection was that PSD should not be published because of this unrelated issue. That did not generate (in my judgement) significant support withing the working group. It's presence in any discussion about PSD is a red herring.


Please explain with some substance.  That is, what is the basis for your conclusion?



5. There is little engagement with the PSD technical effort It is easy to see why owners of some domains would want a mechanism like PSD. As noted, they do have a real and significant problem. So, statements of support from such folk merely confirm their need. (As an aside I'll note that historically the IETF hasn't been all that interested in simplistic statements of support but, rather, actual involvement in the engineering discussion.) What such statements do /not/ provide is any indication that the broader Internet community has an interest in adopting this. First, where are the statements of actively engaged support from an interesting set of organizations on the other side of these queries? In general, there has been a track record of limited adoption for anything that changes infrastructure services, in the absence of a very widespread perception of need, benefit, and tractable operational cost.

I don't think that accurately characterizes the situation for PSD.

That's nice.  Please point to the record of active engagement by both domain owners and those who must implement and run filtering receivers, for this mechanism to be effective.
On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote:
Since we're mentioning a tree walk here, I believe we are ripe for a reopening of that debate.


That's a shame. Besides created additional general cost, it creates an attack vector.


Consider: From foo@bogus.bogus.bogus.bogus.bogus...bogus.bogus.example.com


> 1. These are not 'public' suffixes (1)
 >
> The concept of a 'public' suffix refers to domain names associated with
 > registries subject to externally-imposed operational policies.  For want
 > of a better term, these operations are regulated.  The domain suffixes
 > that PSD attends to are not public registries.
 >

I suspect the name used derives from the name of the resource to which DMARC attached itself early on, namely the Public Suffix List.  Debating its name is probably out of scope here.


It's not, because the term facilitates a basic misunderstanding about the nature of the domain names involved here.  That's why I am raising a concern about the term's use.
And as Alessandro pointed out, the PSL was made for a different purpose and DMARC simply decide to use it to meet its own goals, which in turn supports DMARC distancing itself a bit.

I believe where this is leading, though, is toward the notion that the use of the PSL should be considered external to DMARC.  I don't think anyone has disagreed with that assertion.


And yet both DMARC and PSD have text tied to the term and its function.

> 2. Externalizing internal difficulties
 >
> Some organizations have sub-groups to which various administrative
 > responsibilities have been delegated.  In general, there can be many
 > levels of such delegation.  Not just two.
 >
> For the cases the PSD specification is intended to cover,
 > PSD seeks to adapt to slow DMARC adoption or non-existent domains for
 > one of its delegated sub-groups, by looking for an even-higher-level
 > encompassing record under a next-level Organizational Domain.  That is,
 > PSD is specifying using two different Organizational Domains.  The usual
 > one and its parent.
 >
> A difficulty within the organization is being externalized to a burden
 > for everyone else on the net.

Can you expand on how you see abuse of non-existent domains to be an exploitation of an internal problem?  Specifically, what's the internal problem being exploited?


I apologize for not being more clear about what I meant.  I hope that the above effort elaborate on this suffices.  Basically it concerns an organization's inability to get its subordinates to publish DMARC records and problems with PSLs that lead to identifying the wrong domain as an OD.  Or somesuch...

> 5. There is little engagement with the PSD technical effort
 >
> It is easy to see why owners of some domains would want a mechanism like
 > PSD.  As noted, they do have a real and significant problem.  So,
 > statements of support from such folk merely confirm their need.  (As an
 > aside I'll note that historically the IETF hasn't been all that
 > interested in simplistic statements of support but, rather, actual
 > involvement in the engineering discussion.)
 >
> What such statements do /not/ provide is any indication that the broader
 > Internet community has an interest in adopting this.
 >
> First, where are the statements of actively engaged support from an
 > interesting set of organizations on the other side of these queries?  In
 > general, there has been a track record of limited adoption for anything
 > that changes infrastructure services, in the absence of a very
 > widespread perception of need, benefit, and tractable operational cost..
I don't think that accurately characterizes the situation for PSD.   

I think there's some validity here at least in the claim that the purported interest has not made itself both visible and enthusiastic.  Such dearth absolutely does not rise to the level of supporting something on the standards track, to be sure, but that wasn't the goal here either.


Heh.  An IETF-approved 'experiment' is not a casual activity. A lack of a substantial and wide base of support normally has been significant, even for an IETF-track experimental RFC.


d/

--

Dave Crocker

Brandenburg InternetWorking

bbiw.net

--------------CD1259FD2C2BF79DA8D4A50A-- From nobody Sun Mar 15 11:56:54 2020 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 5792E3A1A93 for ; Sun, 15 Mar 2020 11:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: 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 Z9KaW2cXYDyP for ; Sun, 15 Mar 2020 11:56:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 2B0403A1A92 for ; Sun, 15 Mar 2020 11:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1584298604; bh=2RNTjPqXge+N5nA9esT1JX4SBDZdWzHFeYRCRBEdVZo=; l=3812; h=To:References:From:Date:In-Reply-To; b=BYQzLg2WVyZOhhbMpOCrZC8LPceP6mvtUtQFfWvUI3/Oe4DJnZYw93OvzUOjx5edI MzMBC+ohKwW08ES4rjefcnrWTDRPiV1FTUd3gW0SOWJloQhOfuL//gaVfPlNqe5Zsl /VLFSu3NejCra713C9976CNvXgIC9TqeKID7aa9hNNbOjsk+ZLhysj3L8DfBw Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.131] ([93.37.83.242]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC00B.000000005E6E7A6C.000044B3; Sun, 15 Mar 2020 19:56:44 +0100 To: dmarc@ietf.org References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> <856481e5-7497-ba81-fb1f-dba2b645276c@tana.it> <378e83ae-f326-695c-a3c2-d0e099fd97b4@dcrocker.net> From: Alessandro Vesely Message-ID: <075b4f3a-53ae-31b2-904d-0fb6752bf3fd@tana.it> Date: Sun, 15 Mar 2020 19:56:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <378e83ae-f326-695c-a3c2-d0e099fd97b4@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Public suffix and 3rd level, was Summary comments 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: Sun, 15 Mar 2020 18:56:52 -0000 Hi, I changed the subject as I only reply to that part of the original post. On Sun 15/Mar/2020 13:49:26 +0100 Dave Crocker wrote: > On 3/11/2020 10:08 AM, Alessandro Vesely wrote: >>> 1. These are not 'public' suffixes (1) The concept of a 'public' >>> suffix refers to domain names associated with registries subject to >>> externally-imposed operational policies.  For want of a better >>> term, these operations are regulated.  The domain suffixes that PSD >>> attends to are not public registries. >> ... For "public suffix", I propose we stick to the definition >> referred by rfc8499. > > OK, let's do that: > >      "Public suffix: "A domain that is controlled by a public registry." > > > I gave three examples of types of domains, like the owner of > example.com getting .example.  In each of those 3 cases, these domain > names are not controlled by a public registry.  So they are not > "public suffix domains". I agree that that definition is not all that well reasoned. Are there private registries? Rfc8499 also talks about "public DNS", where the adjective bears a slightly different meaning. We need to define Operational Domain. Debating about the semantic meaning of "public" doesn't seem to help much. >>> 3. DMARC wants the Organizational Domain The existing DMARC model >>> is a) look under the full domain, and then b) look under the >>> Organizational Domain, as a fallback.  My strong suggestion is to >>> keep the model as simple as that. The argument for adding just this >>> one more layer of Organizational Domain seems modest, primarily >>> because it is purpose-built to handle a new, special case, rather >>> than because it represents a considered, general case. >> Having three levels instead of two sounds quite general. > > That's nice.  And there is a common computer science view that it can > be.  But in this case it isn't true.  Rather, it is a very > specialized, purpose-built addendum.  There is nothing general about > it at all. It would certainly be more general if there was a way to specify it independently of the public suffix list. Let me quote another paragraph of yours, which describes the problem well: > [...] > The organization that controls this bit of hierarchy controls the > domain name the PSD draft is seeking to identify and use.  It also > controls the one below it that is otherwise viewed as the > organizational domain.  For some organizations, there will be other > administrative boundaries, below this, for subordinate companies or > departments, or the like. For large, complex organizations, there can > be an extensive administrative hierarchy and it might be reflected in > a large, complex domain name hierarchy. The non-general way to define a 3rd level is to have the top suffix be "public" (in the sense of the PSL) and then have the organization participate in PSD DMARC. According to the experiment, that allows subordinate companies or departments to publish their own policy, and still have an top-level policy as a default and for non-existent domains. I agree that having to call "pubic" an organization just because it is so wide as to require three levels doesn't seem to be semantically consistent. The mechanism works, though, and covers known use cases. The general way would allows example.com to behave like .example without disturbing the registries and the PSL. However, to work out what mechanisms are needed is daunting. Any suggestion on how to shape that? To me, it seems it would likely require more radical changes to DMARC than the low hanging fruit at hand. In addition, we would then have the problem of how to define "private" the relevant TLDs, despite their ICANN agreement. Best Ale -- From btv1==34399b1a4e9==fosterd@bayviewphysicians.com Sun Mar 15 13:33:14 2020 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 964683A1BD5 for ; Sun, 15 Mar 2020 13:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 G0xxFFa-Volz for ; Sun, 15 Mar 2020 13:33:13 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A0D3A1BD4 for ; Sun, 15 Mar 2020 13:33:13 -0700 (PDT) X-ASG-Debug-ID: 1584304391-11fa3117c31a650001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 3fqJrGWQWTq5SLCn (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 15 Mar 2020 16:33:11 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=+n5bXz4hoSHHrBW1nZyIqmKJAsljbPUBFznKAW/dVtI=; b=QrLBlsszcq2psPj+IAotIzu0h5cymapvyez5j0M2AORy/7bm9hgioP3kDMZnNJfoB U1bqopww+GMVY87VSyCydVViasUECjd1lXOApuNM9zDsAzeYmFXYa376dWhfD7jOf Bxt5ZFyLpg8Ac0PqTJKdV7v7KIete5fu4GXsmqmgA= From: "Douglas E. Foster" To: Date: Sun, 15 Mar 2020 20:33:02 GMT X-ASG-Orig-Subj: The case for walking the domain Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=c01a2495024e4323ae5713a52816794e X-Exim-Id: ac5dfd883a8346abbe2423cfc176d503 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1584304391 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4204 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC5_SA210e, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80624 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SC5_SA210e Custom Rule SA210e Archived-At: Subject: [dmarc-ietf] The case for walking the domain 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: Sun, 15 Mar 2020 20:34:23 -0000 This is a multipart message in MIME format. --c01a2495024e4323ae5713a52816794e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The brilliance of DMARC is in its feedback mechanism. For that feedback t= o be useful, it needs to reach someone who can act on it. For a massive o= rganization like the U.S. Government, I cannot imagine how feedback to a .g= ov catchall account could be actionable. Suppose someone decides to send a newsletter to local farmers, from the Kan= sas office of the Agricultural Extension program of the Department of Agric= ulture. He creates an account with Constant Contact and starts sending mes= sages.. This violates the DMARC policy of Dept of Agriculture, so someone in D.C. s= tarts getting notifications that Gmail is blocking lots of messages from Co= nstant Contact. What is to be done? The "mail integrity program officer" of the Department of Agriculture calls= Constant Contact, but they politely explain that they need proof of identi= ty, which can be: Knowledge of the login credentials for the Constant Contact account, orA co= urt order Eventually our "Mail Integrity" officer gets his court order and forces the= account to be closed. The farmer outreach officer in Kansas suddenly find= s his Constant Contact account disabled, so he creates a new one. All of t= his gets in the way of actually communicating with farmers who will benefit= from the newsletter. The internal communication problems will be difficult even if the Constant = Contact account is tied to a valid subdomain of Agriculture, with a DMARC p= olicy on that subdomain. It becomes exponentially more difficult if the ne= wsletter uses a non-existent subdomain, causing the feedback to go to a cat= chall account for Department of Agriculture or worse yet a catchall account= for all of ".gov" Walking the domain allows feedback, for both valid and non-existent domains= , to go to the destination most able to use the information, and makes the = .gov policy a trivial extension of the domain walk. Doug Foster . --c01a2495024e4323ae5713a52816794e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
The brilliance of = DMARC is in its feedback mechanism.   For that feedback to be useful, = it needs to reach someone who can act on it.   For a massive organizat= ion like the U.S. Government, I cannot imagine how feedback to a .gov catch= all account could be actionable.

Suppose someone d= ecides to send a newsletter to local farmers, from the Kansas office of the= Agricultural Extension program of the Department of Agriculture.  He = creates an account with Constant Contact and starts sending messages..

This violates the DMARC policy of Dept of Agriculture,= so someone in D.C. starts getting notifications that Gmail is blocking lot= s of messages from Constant Contact.   What is to be done?
<= br>
The "mail integrity program officer" of the Department of Agr= iculture calls Constant Contact, but they politely explain that they need p= roof of identity, which can be:
  • Knowledge of the login credent= ials for the Constant Contact account, or
  • A court order
Eventually our "Mail Integrity" officer gets his court order and forces = the account to be closed.  The farmer outreach officer in Kansas sudde= nly finds his Constant Contact account disabled, so he creates a new one. &= nbsp;All of this gets in the way of actually communicating with farmers who= will benefit from the newsletter.

The internal co= mmunication problems will be difficult even if the Constant Contact account= is tied to a valid subdomain of Agriculture, with a DMARC policy on that s= ubdomain.  It becomes exponentially more difficult if the newsletter u= ses a non-existent subdomain, causing the feedback to go to a catchall acco= unt for Department of Agriculture or worse yet a catchall account for all o= f ".gov"

Walking the domain allows feedback, for b= oth valid and non-existent domains, to go to the destination most able to u= se the information, and makes the .gov policy a trivial extension of the do= main walk.

Doug Foster

.&= nbsp;




--c01a2495024e4323ae5713a52816794e-- From nobody Wed Mar 18 10:14:28 2020 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B143A18F2; Wed, 18 Mar 2020 10:14:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk CC: dmarc@ietf.org, superuser@gmail.com, draft-ietf-dmarc-psd@ietf.org, alexey.melnikov@isode.com, Murray Kucherawy , dmarc-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158455166524.29929.12816688425406910940@ietfa.amsl.com> Date: Wed, 18 Mar 2020 10:14:25 -0700 Archived-At: Subject: [dmarc-ietf] Last Call: (DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)) to Experimental RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 18 Mar 2020 17:14:25 -0000 The IESG has received a request from the Domain-based Message Authentication, Reporting & Conformance WG (dmarc) to consider the following document: - 'DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-04-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. Domains at which registrations can occur are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. This document also seeks to address implementations that consider a domain on a public Suffix list to be ineligible for DMARC enforcement. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Mar 18 16:29:57 2020 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 A2C8F3A0986 for ; Wed, 18 Mar 2020 16:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 VTJgpMGm3elC for ; Wed, 18 Mar 2020 16:29:53 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 A8C583A098A for ; Wed, 18 Mar 2020 16:29:53 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id s194so187054vkb.11 for ; Wed, 18 Mar 2020 16:29:53 -0700 (PDT) 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=zNp70waff63RgfyxN17JtLRgP8++AfDMnjtCc+HxDp8=; b=MQscjxODIrn+58O0hu+9WTL+zU+RKy+uxMqYUf4+FFWC3uX02aqxkarDcIk6sZacQM wxDVpwXGK7vwToY1wGqrXrO2mh2ENazTaNfWeSwrdX5T2ylL8vdtIJ3EVnp4Rfyxc9Zg qWCjNN5hA/4k1y4wZPw1hlpH5pzcwJSv5eIW8IMN/ChIrBK3yHP2mFlrc5ReXvWramdw 8ourzLymZ6132+/N7YXpgLnt6JdRMusjd72Jzk0ehGUKiMi91Pb7H2GnNNxuyXQ+9TF3 qr2UUE6g3XJSp5Ffrc9w8gCmNcSrHXA1dGb8Z0tQnB9JqIrr5ab1HPINY7CVw0JDHLTa l6mg== 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=zNp70waff63RgfyxN17JtLRgP8++AfDMnjtCc+HxDp8=; b=sq28cVMa9wr7Oh49dyvwCB0Up+9dTtBut9HDr7yK9odGo3XKXxwzo9K11g0cIW13iN xQV26uKKevfenWO+AEF5YoS/P4H/HpjIqMMgTZtmpU8AgDSawORd0u+Mgyj4PL7tI9fV OOsSsi/jkmTxwlqRCz13nE1mbf05lBKqaxWfoXUCtYnj6GOrRWyzT7iuAklwHstNDUA4 S2UBGUrMUrjRow33bmwx2jRx/B7hp4L9gijGcsvsT2lBir64zN89q4eSlyBlp6dela2g Ty/RbRdQgxcxV6zK7XrwCtb8EJj3uw3AmFAn4LRpj6rh1pUaLQhFYYVlt3w2kKKCTYo6 zuMw== X-Gm-Message-State: ANhLgQ25dapJv/mfNAOZHOSpK8vAd84de8VrBBZ9lzvihrJ+EdQSNMoK qLGVcwlP5gRzoGycbZrfp7fP427WC92pk/Nh+M4XrnxK X-Google-Smtp-Source: ADFU+vvEQDOuSjbi2fx5+O9c+0WGonVUzLmNotYgnTA3X9wMnE9gCdPa1griGKz9/hz7Cg6xNk1Z8i5qvfQUrwRBgAY= X-Received: by 2002:a1f:188f:: with SMTP id 137mr550337vky.95.1584574192625; Wed, 18 Mar 2020 16:29:52 -0700 (PDT) MIME-Version: 1.0 References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> <856481e5-7497-ba81-fb1f-dba2b645276c@tana.it> <378e83ae-f326-695c-a3c2-d0e099fd97b4@dcrocker.net> In-Reply-To: <378e83ae-f326-695c-a3c2-d0e099fd97b4@dcrocker.net> From: "Murray S. Kucherawy" Date: Wed, 18 Mar 2020 16:29:41 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000df2c8005a1296d9e" Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Wed, 18 Mar 2020 23:29:56 -0000 --000000000000df2c8005a1296d9e Content-Type: text/plain; charset="UTF-8" On Sun, Mar 15, 2020 at 5:49 AM Dave Crocker wrote: > On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote: > > Since we're mentioning a tree walk here, I believe we are ripe for a > reopening of that debate. > > That's a shame. Besides created additional general cost, it creates an > attack vector. > > Consider: From foo@bogus.bogus.bogus.bogus.bogus...bogus.bogus.example.com > Yeah, I'm familiar with the nature of the attack. But based on what amounts to the hallway track, it feels like the perspective of the DNS community these days is that the currently deployed DNS infrastructure could easily deal with such an attack, to at least the extent that it's not a blocker for something potentially useful like resolving the Organizational Domain problem for DMARC. Tim might be able to elucidate here. I believe where this is leading, though, is toward the notion that the use > of the PSL should be considered external to DMARC. I don't think anyone > has disagreed with that assertion. > > And yet both DMARC and PSD have text tied to the term and its function. > My point here is that I believe we've already agreed that you're correct, and this separation should happen, but there's no apparent urgency that MUST be done before the PSD experiment can proceed. Indeed, I'm fairly certain the amount of code change in my own implementation in order to be compliant with such a change in the specification is around zero. The audience for the experiment, by my read, also agrees, so they understand the need, but this won't change the experiment either. > > > 2. Externalizing internal difficulties >> > >> > Some organizations have sub-groups to which various administrative >> > responsibilities have been delegated. In general, there can be many >> > levels of such delegation. Not just two. >> > >> > For the cases the PSD specification is intended to cover, >> > PSD seeks to adapt to slow DMARC adoption or non-existent domains for >> > one of its delegated sub-groups, by looking for an even-higher-level >> > encompassing record under a next-level Organizational Domain. That is, >> > PSD is specifying using two different Organizational Domains. The usual >> > one and its parent. >> > >> > A difficulty within the organization is being externalized to a burden >> > for everyone else on the net. >> > > Can you expand on how you see abuse of non-existent domains to be an > exploitation of an internal problem? Specifically, what's the internal > problem being exploited? > > I apologize for not being more clear about what I meant. I hope that the > above effort elaborate on this suffices. Basically it concerns an > organization's inability to get its subordinates to publish DMARC records > and problems with PSLs that lead to identifying the wrong domain as an OD. > Or somesuch... > The issue PSD is attempting to address is mail sent as a nonexistent subdomain. For example, irs.gov doesn't have a subdomain called auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could send email as msk@auditors.irs.gov without limitation. The goal here is to come up with a mechanism to prevent this. Obviously the maintainers of irs.gov can't anticipate all possible nonexistent names that might be used, so either something like PSD is needed, or some kind of wildcarding mechanism is needed by which the domain owner can block any name they're not actually using. What such mechanism could be developed? Don't wildcard TXT records, for example, have some other side effects? -MSK --000000000000df2c8005a1296d9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 15, 2020 at 5:49 AM Dave Croc= ker <dhc@dcrocker.net> wrote<= tt>:
On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote:
Since we're mentioning a tree walk here, I believe we are ripe for a reopening of that debate.
=20

That's a shame. Besides created additional general cost, it creates an attack vector.

=20

Consider: From foo@bogus.bogus.bogus.bogus= .bogus...bogus.bogus.example.com

Yeah, = I'm familiar with the nature of the attack. =C2=A0 But based on what am= ounts to the hallway track, it feels like the perspective of the DNS commun= ity these days is that the currently deployed DNS infrastructure could easi= ly deal with such an attack, to at least the extent that it's not a blo= cker for something potentially useful like resolving the Organizational Dom= ain problem for DMARC.

Tim might be able to elucidate here.
I believe where this is leading, though, is toward the notion that the use of the PSL should be considered external to DMARC.=C2=A0 I don't think anyone has disag= reed with that assertion.
=20

And yet both DMARC and PSD have text tied to the term and its function.

My point here is that I b= elieve we've already agreed that you're correct, and this separatio= n should happen, but there's no apparent urgency that MUST be done befo= re the PSD experiment can proceed.=C2=A0 Indeed, I'm fairly certain the= amount of code change in my own implementation in order to be compliant wi= th such a change in the specification is around zero.=C2=A0 The audience fo= r the experiment, by my read, also agrees, so they understand the need, but= this won't change the experiment either.

> 2. Externalizing internal difficulties
 >
> Some organizations have sub-groups to which various administrative
 > responsibilities have been delegated.=C2=A0 In general, there can be many
 > levels of such delegation.=C2=A0 Not just two.=
>
> For the cases the PSD specification is intended to cover,
 > PSD seeks to adapt to slow DMARC adoption or non-existent domains for
 > one of its delegated sub-groups, by looking for an even-higher-level
 > encompassing record under a next-level Organizational Domain.=C2=A0 That is,
 > PSD is specifying using two different Organizational Domains.=C2=A0 The usual
 > one and its parent.
 >
> A difficulty within the organization is being externalized to a burden
 > for everyone else on the net.

Can you expand on how you see abuse of non-existent domains to be an exploitation of an internal problem?=C2=A0 Specifically, what's the internal problem being exploited?
=20

I apologize for not being more clear about what I meant.=C2=A0 I hope that the above effort elaborate on this suffices.=C2=A0 Basically it concerns an organization's inability to get its subordinates to publish DMARC records and problems with PSLs that lead to identifying the wrong domain as an OD.=C2=A0 Or somesuch...

The issue PSD is attemp= ting to address is mail sent as a nonexistent subdomain.=C2=A0 For example,= irs.gov doesn't have a subdomain called= auditors.irs.gov, so irrespective = of any irs.gov DMARC policy, I could send em= ail as msk@auditors.irs.gov wit= hout limitation.=C2=A0 The goal here is to come up with a mechanism to prev= ent this.=C2=A0 Obviously the maintainers of irs= .gov can't anticipate all possible nonexistent names that might be = used, so either something like PSD is needed, or some kind of wildcarding m= echanism is needed by which the domain owner can block any name they're= not actually using.=C2=A0 What such mechanism could be developed?=C2=A0 Do= n't wildcard TXT records, for example, have some other side effects?

-MSK
--000000000000df2c8005a1296d9e-- From nobody Wed Mar 18 18:17:09 2020 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 DD41B3A1B73 for ; Wed, 18 Mar 2020 18:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Yu0hAPLU; dkim=pass (1536-bit key) header.d=taugh.com header.b=h35vg/Gs 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 Jp7N_vKL6RXW for ; Wed, 18 Mar 2020 18:17:06 -0700 (PDT) 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 E2D3E3A1A6A for ; Wed, 18 Mar 2020 18:17:05 -0700 (PDT) Received: (qmail 38758 invoked from network); 19 Mar 2020 01:17:04 -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=9760.5e72c810.k2003; bh=HqPPd8KUrSK0LAj3PMHoIcdUsvGk0MVerpZId56abGA=; b=Yu0hAPLUTFEeucCKEGrnqY1Vn98Fu/K1hVKh9v0hAY0T917Ys85g5l1nLM6xtUFc8rgtE3JEv7P8rb3TEbiOo8XbwpFLB1ET4KnNGq4hVLGDrd4MlshI5BfvaF6Xe/OAfWeSGEVj4U7p7nFYTOG/0uJC6rCXz0LWWYADcantHgsv6fHEZOYr/g2sI23kEJJLVARs5QFkQwnDfEwBgZe/rwnyV4JyVOZ7PvevXWoOF6fFNHawTQaLkA/6dJGDoGV2 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=9760.5e72c810.k2003; bh=HqPPd8KUrSK0LAj3PMHoIcdUsvGk0MVerpZId56abGA=; b=h35vg/GsLUqetLHp51uBGaAsRo1jtdWtFXZmQlDZJz22HIItFsym7cRM9+2NMZeh9UCFPV3e6apWDyDmHcN48Y0GfIFLOUXlbQ58AFcP1PtgxS42jEcjrfDLW6pkziGt3778Kf23xNJfvUuNQxt3VP1hg7BSIa7+RjXSgARAAbOfwxKHSh6qHboBIEPVJmpLoBam9bLoi7U0I3vP7AQ1UnWHPi6mHGg9dpx6vLN2oI4fPLphD/RtymD00DYdYBHj 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 ESMTP via TCP6; 19 Mar 2020 01:17:04 -0000 Received: by ary.qy (Postfix, from userid 501) id E1A70163EB3F; Wed, 18 Mar 2020 21:17:03 -0400 (EDT) Date: 18 Mar 2020 21:17:03 -0400 Message-Id: <20200319011703.E1A70163EB3F@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] Summary comments 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: Thu, 19 Mar 2020 01:17:09 -0000 In article you write: >> Consider: From foo@bogus.bogus.bogus.bogus.bogus...bogus.bogus.example.com >> >Yeah, I'm familiar with the nature of the attack. But based on what >amounts to the hallway track, it feels like the perspective of the DNS >community these days is that the currently deployed DNS infrastructure >could easily deal with such an attack, ... The DNS crowd is finally admitting to themselves that Sturgeon's Law applies to the DNS, too, and a little more crud will be lost in the large amoung ot noise. I gather than people are implementing RFC 8020 which makes this attack less effective. >The issue PSD is attempting to address is mail sent as a nonexistent >subdomain. For example, irs.gov doesn't have a subdomain called >auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could send >email as msk@auditors.irs.gov without limitation. ... I have less sympathy for that argument. I do a hard reject of any mail with a nonexistent bounce address which I don't think is unusual. PSD as I understand it is to address the same issue the organizational domain does, but a level up, in a group of organizations that have some administrative connection. The issue is people who publish A and MX records without covering DMARC records. They're not supposed to do that but they do, and PSD is one way of figuring out who needs to fix what. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Mar 19 04:41:27 2020 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 9F69D3A27D1 for ; Thu, 19 Mar 2020 04:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: 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 eE_nE1ChrchO for ; Thu, 19 Mar 2020 04:41:15 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 4F1B33A27CC for ; Thu, 19 Mar 2020 04:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1584618064; bh=bNBPKKlFLi6l7hHZGW3gCYivKWO4wiQqT90Rl8FQER4=; l=837; h=To:References:From:Date:In-Reply-To; b=A0uUtspQmabGzx4jJCcaa1qW0T1eENLqZdVGSBw2w35GizVFRYfSrieHS8w0Bfr6z 7lB5kTwcSGDQUxChHCrg/lufayPuX6XoY48qZUxHRVF+l93zXBL0/RpTaLtHxWW0EM 2Wr6mHfocO3yHMPeogEauOqfCX/tjWZWU60ucSlcyfB4EiJR4PWSUcN3S9BY/ 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC077.000000005E735A50.00006AC4; Thu, 19 Mar 2020 12:41:04 +0100 To: dmarc@ietf.org References: <20200319011703.E1A70163EB3F@ary.qy> From: Alessandro Vesely Message-ID: Date: Thu, 19 Mar 2020 12:41:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200319011703.E1A70163EB3F@ary.qy> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Thu, 19 Mar 2020 11:41:25 -0000 On Thu 19/Mar/2020 02:17:03 +0100 John Levine wrote: > > I do a hard reject of any mail with a nonexistent bounce address which I > don't think is unusual. How about nonexistent From: address domain? Rejecting these is less usual (IME because of joe@NOSPAMexample.com) although DMARC shifted the accent here. > PSD as I understand it is to address the same issue the organizational > domain does, but a level up, in a group of organizations that have > some administrative connection. The issue is people who publish A and > MX records without covering DMARC records. They're not supposed to do > that but they do, and PSD is one way of figuring out who needs to fix what. It also covers From: trustme@nonexistent.mil. That way we can reject on nonexistent From: addresses for a subset of PSDs. Best Ale -- From nobody Fri Mar 20 10:05:09 2020 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 8BE9B3A0BFA for ; Fri, 20 Mar 2020 10:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 76Y3AEse9GyQ for ; Fri, 20 Mar 2020 10:04:58 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 04D4A3A0C63 for ; Fri, 20 Mar 2020 10:04:57 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id k26so6694990otr.2 for ; Fri, 20 Mar 2020 10:04:57 -0700 (PDT) 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; bh=NWJBKkpVUUa0hjKwm9e9xDXMdPDQ4IZJSnSHK0tkgVs=; b=aaPGVZYHWQKOHrWfU3HawxJG14RMJUgMxRttUKsRxMuxylvyFKJcHwMyMDm6qH0IHo rlOTgg0xwdu+0KtVZcL60xFz1UiKs7B0M8EO2v9qYcYtw38Vwak4ojZjBQhY7TBHcyS5 6NtHCdRsrTTApvVxhfa75NJfdejI9KjMIe5gzqie7HhmldT48lrc0Pvb8YdlrjRfBsJ9 22f9lFIG0zHVQbGj2LWfFMBsOwdxzXNVV0xqb+JmNtuJrStt/BbeE9hkMuSrE7HfcHHA LQ5Qy+X6tY8akPZ4xjqj9VTZpXkDG6VWcekoAWDm8Ab3QYeu27z+6e4TvPmkJmpnMuEK sv0Q== 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; bh=NWJBKkpVUUa0hjKwm9e9xDXMdPDQ4IZJSnSHK0tkgVs=; b=FzonAkv2rWqVVZOGdzHA7ePMCyHYMp1LlbVWKzdnRLFaqyKL3ThbQS9mYkSAeyqrDt uuQRGt6ffHNv7O8zE0w+8OQbc7QPYSOy8iQGTt9zy0YnlyAJBdurhl6VehG9X3Tventc BzeWlGDagFc4QSECqkRrPvRYP4S7XXZnlf032pVvFjF3gtqPnWp1JPXUUUszEqp73d3P 9PgKyNIngJ25p4zLxFWOxtCdnCOVEVJVlm7Xu9VREIZClLBR268Ck4elYiqRMFULxbSo nJyW/OWX4LXAiLwylJ6yyXocgMdA4vv7sEZs10YsuPNJrLHM3d0/GyTlfuMjYZWlwpmS J1vw== X-Gm-Message-State: ANhLgQ3gece10FFuv0c1xHcoz+OR64NffC+iNYVfMbO4lWnGEJFkUg+E SB5T/L7ODU+JI3PN2YjAbq6bxLUREcjAhN7s9Gg/RuP7 X-Google-Smtp-Source: ADFU+vs/4r1qiJUMBmfyj6wQ7v/EKYDI1b3N6ev59UvBouXznW6ZMIfUPw4GL7puXh+/CsrZeiQE+3HXcq6lTqqXvig= X-Received: by 2002:a05:6830:118d:: with SMTP id u13mr7217332otq.41.1584723896217; Fri, 20 Mar 2020 10:04:56 -0700 (PDT) MIME-Version: 1.0 References: <158472349514.13563.10473535382783641013@ietfa.amsl.com> In-Reply-To: <158472349514.13563.10473535382783641013@ietfa.amsl.com> From: Tim Wicinski Date: Fri, 20 Mar 2020 13:04:44 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e6d6c005a14c4832" Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-dmarcbis-00.txt 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, 20 Mar 2020 17:05:06 -0000 --000000000000e6d6c005a14c4832 Content-Type: text/plain; charset="UTF-8" All I have some Copious Spare Time, so I started doing the work of submitting DMARC-bis What was done: - imported rfc 7489 text - updated errata https://www.rfc-editor.org/rfc/inline-errata/rfc7489.html#eid5440 - updated references to use RFCXXXX nomenclature - updated internal references - opened issue to update obsolete RFC refs (7001/5226) - opened issue to update IANA considerations to reflect the _underscore registry RFC8552 - added myself as editor What is missing: - Definitions have some minor formatting nits - [FIXTHIS: Reference to [RFC3986] in code block] Location: https://github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis All open issues are currently in the issue tracker https://trac.ietf.org/trac/dmarc/report/1 ---------- Forwarded message --------- From: Date: Fri, Mar 20, 2020 at 12:58 PM Subject: New Version Notification for draft-kucherawy-dmarc-dmarcbis-00.txt To: Murray S. Kucherawy , Tim Wicinski < tjw.ietf@gmail.com>, Elizabeth Zwicky A new version of I-D, draft-kucherawy-dmarc-dmarcbis-00.txt has been successfully submitted by Tim Wicinski and posted to the IETF repository. Name: draft-kucherawy-dmarc-dmarcbis Revision: 00 Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Document date: 2020-03-20 Group: Individual Submission Pages: 72 URL: https://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-dmarcbis-00.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/ Htmlized: https://tools.ietf.org/html/draft-kucherawy-dmarc-dmarcbis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kucherawy-dmarc-dmarcbis Abstract: Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000e6d6c005a14c4832 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All

I have some Copious = Spare Time, so I started doing the work of submitting=C2=A0 DMARC-bis=C2=A0=


What was done:


- imported rfc 7489 text

- updated errata https://ww= w.rfc-editor.org/rfc/inline-errata/rfc7489.html#eid5440

- updated references to use RF= CXXXX nomenclature

- updated internal references<= span class=3D"gmail-Apple-converted-space">=C2=A0

- opened issue to update obsol= ete RFC refs (7001/5226)=C2=A0<= /span>

- opened issue to update IANA considerations to ref= lect the _underscore registry RFC8552

- added myself as editor=C2=A0


What is missing:

- Definitions have some minor = formatting nits=C2=A0

- [FIXTHIS: Reference to [RFC3= 986] in code block]


Location:=C2=A0 =C2=A0 https://= github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis

All open issues are = currently in the issue tracker

h= ttps://trac.ietf.org/trac/dmarc/report/1




---------- Forwarded message ---------<= br>From: <internet-drafts@ietf.org>
Date: Fri, Mar 20, 2020 at 12:5= 8 PM
Subject: New Version Notification for draft-kucherawy-dmarc-dmarcbi= s-00.txt
To: Murray S. Kucherawy <superuser@gmail.com>, Tim Wicinski <tjw.ietf@gmail.com>, Elizabeth Zwicky <zwicky@yahoo-inc.com>


A new version of I-D, draft-kucherawy-dmarc-dmarcbis-00.txt
has been successfully submitted by Tim Wicinski and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kucherawy-dmarc-dmarcbi= s
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Domain-based Message Authenticatio= n, Reporting, and Conformance (DMARC)
Document date:=C2=A0 2020-03-20
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 72
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-kucherawy-dm= arc-dmarcbis-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-kucherawy-dmarc-dmarcbis-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-kucherawy-dmarc-dmarcbis


Abstract:
=C2=A0 =C2=A0Domain-based Message Authentication, Reporting, and Conformanc= e
=C2=A0 =C2=A0(DMARC) is a scalable mechanism by which a mail-originating =C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting, that a mail-re= ceiving
=C2=A0 =C2=A0organization can use to improve mail handling.

=C2=A0 =C2=A0Originators of Internet Mail need to be able to associate reli= able
=C2=A0 =C2=A0and authenticated domain identifiers with messages, communicat= e
=C2=A0 =C2=A0policies about messages that use those identifiers, and report= about
=C2=A0 =C2=A0mail using those identifiers.=C2=A0 These abilities have sever= al benefits:
=C2=A0 =C2=A0Receivers can provide feedback to Domain Owners about the use = of
=C2=A0 =C2=A0their domains; this feedback can provide valuable insight abou= t the
=C2=A0 =C2=A0management of internal operations and the presence of external= domain
=C2=A0 =C2=A0name abuse.

=C2=A0 =C2=A0DMARC does not produce or encourage elevated delivery privileg= e of
=C2=A0 =C2=A0authenticated email.=C2=A0 DMARC is a mechanism for policy dis= tribution
=C2=A0 =C2=A0that enables increasingly strict handling of messages that fai= l
=C2=A0 =C2=A0authentication checks, ranging from no action, through altered=
=C2=A0 =C2=A0delivery, up to message rejection.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--000000000000e6d6c005a14c4832-- From nobody Fri Mar 20 12:38:47 2020 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 D22C33A0D44 for ; Fri, 20 Mar 2020 12:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0idruKoFEZcO for ; Fri, 20 Mar 2020 12:38:40 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 358373A0C32 for ; Fri, 20 Mar 2020 12:38:40 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id k8so7827015oik.2 for ; Fri, 20 Mar 2020 12:38:39 -0700 (PDT) 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; bh=sWegkz7o3AQDwWo9BAsB65A9ttHxwkuhhPHebnmlVlM=; b=h/wdoGdhjnC/YlmBNjD8OgFKDeG7Eu+9cQJjE2aPq4Akw9gyllc0TScf6TIdvMvZ7Y rHF2oSWF0anPEN+IzKrtZhw+WHNdiWtsUVW8KAbxM/e2UUFHBKYCdRVC0OwF56K/hqJA x1a/ZDSgxyG1MduuLdOG62b9hLSiUAmU+qrSnsW6UbVhgg4Rwv/i1xzvwTQTU/hHhO1G slcqhcd3Ndzmz4YfrjCO9dgSgjottnrsUnESaszr3EerXQXvqA781ZJJtV9DxHQpjHo6 JV0ynTDPkddYgJkIiPRprQyrA7/LmLoTT5oxczPUxGE+TkNizbC8Pj7d18RhF3VGHU67 58WQ== 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; bh=sWegkz7o3AQDwWo9BAsB65A9ttHxwkuhhPHebnmlVlM=; b=HU1kJfQsiP2sJjhzAvXNu/D3eRRhlbVbvBZqO4C0+Te14QPkciQou6q1hiN2B6xcQ3 zlO9hpIBI9AmfjgYvD99EpXgZdBir8u6XNXENqv0pLL0rUqwYPlnoZSlaPUoBAn/cW0a y86duNLPzb7r7so9RD/j5eQnX5eF9rgSIS3YYOeA6zSolSGlMP+2FVTajF8KIu4qsyLP 0qZj+GNGt22kDeWMAsEHrX5PIPueDvTytwTn467ofyGTJsqUvm3nru+McJx48OxZiWup vq7Bu6o8seNmcGZ1torForMRIS8JWgNqsEhYKA61Bo0+Wre7gBhkNiLtXQllRob/lg/n E7Vg== X-Gm-Message-State: ANhLgQ2XHyxkboo70Vy/iQZ12rHKfAYOSaKlYW1mweMP+kc9pD0DZzDf eoKh/zpMEEcVsOjiWcUUUeLn2ne3z35TN8d+20adQQ== X-Google-Smtp-Source: ADFU+vtfxz31SiA53rauuWwwUnyF+iVognK0lcLBt86qz5iSz/iIcwJpAEDJviPbmldLhIa7kKhQJMMpZTjoUWEeAmE= X-Received: by 2002:a54:4496:: with SMTP id v22mr8060954oiv.132.1584733118630; Fri, 20 Mar 2020 12:38:38 -0700 (PDT) MIME-Version: 1.0 References: <20200319011703.E1A70163EB3F@ary.qy> In-Reply-To: <20200319011703.E1A70163EB3F@ary.qy> From: Tim Wicinski Date: Fri, 20 Mar 2020 15:38:26 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009990c205a14e6e43" Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Fri, 20 Mar 2020 19:38:44 -0000 --0000000000009990c205a14e6e43 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 18, 2020 at 9:17 PM John Levine wrote: > In article 5WSH0xLUijs48FWB00vbQ49g@mail.gmail.com> you write: > >> Consider: From foo@bogus.bogus.bogus.bogus.bogus... > bogus.bogus.example.com > >> > >Yeah, I'm familiar with the nature of the attack. But based on what > >amounts to the hallway track, it feels like the perspective of the DNS > >community these days is that the currently deployed DNS infrastructure > >could easily deal with such an attack, ... > > The DNS crowd is finally admitting to themselves that Sturgeon's Law > applies to the DNS, too, and a little more crud will be lost in the > large amoung ot noise. I gather than people are implementing RFC 8020 > which makes this attack less effective. > > +1 to what John says here. I mean, I was still seeing a non-trivial number of A6 queries. tim --0000000000009990c205a14e6e43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 18, 2020 at 9:17 PM John Levine &= lt;johnl@taugh.com> wrote:
In article <CAL0qLw= Zwz+R52ydEgn7Qpu8t4=3D5WSH0xLUijs48FWB00vbQ49g@mail.gmail.com> you= write:
>> Consider: From foo@bogus.bogus.bogus.bogus.bogus...bogus.bogu= s.example.com
>>
>Yeah, I'm familiar with the nature of the attack.=C2=A0 =C2=A0But b= ased on what
>amounts to the hallway track, it feels like the perspective of the DNS<= br> >community these days is that the currently deployed DNS infrastructure<= br> >could easily deal with such an attack, ...

The DNS crowd is finally admitting to themselves that Sturgeon's Law applies to the DNS, too, and a little more crud will be lost in the
large amoung ot noise.=C2=A0 I gather than people are implementing RFC 8020=
which makes this attack less effective.


+1 to what John says here.=C2=A0 =C2=A0I mean, I was stil= l seeing a non-trivial number of A6 queries.=C2=A0

tim
=C2=A0
--0000000000009990c205a14e6e43-- From rfc@arcsin.de Sat Mar 21 16:23:53 2020 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 646B33A0783 for ; Sat, 21 Mar 2020 16:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 jHCqM3iiKbyj for ; Sat, 21 Mar 2020 16:23:51 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23C23A077A for ; Sat, 21 Mar 2020 16:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id :references:subject:subject:from:from:x-amavis-category; s= dkim01; t=1584833024; x=1586647425; bh=N7BXADpBGge8gnqDbO1FOXFLP zT/M4fuEaAnyGfRolc=; b=HsTjIAWqehDk7lD27j0voQpMQ97JErA1BWFhnpNWz ziFYuoNBntUEoS4upfhqeouZKjqPHuu8JuNUNLKl/0Mkf3rp0BCzBnpNPCtGyAOE 5fW3gTH/Pz8TBgX8iw55t8e9A1LIFZ2qFOFLJNSUfuQO63a49rGpnNyZBUKnasBE 4k= X-Amavis-Category: scalar.arcsin.de; category=CleanTag From: Damian Lukowski References: <358069c2-4654-83cb-f800-4e3e33952c7f@arcsin.de> <1791077f-7d4e-de24-8720-0b19f601b2ba@gmail.com> To: dmarc@ietf.org Message-ID: Date: Sun, 22 Mar 2020 00:24:11 +0100 MIME-Version: 1.0 In-Reply-To: <1791077f-7d4e-de24-8720-0b19f601b2ba@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 21 Mar 2020 17:31:11 -0700 Subject: Re: [dmarc-ietf] [rfc-i] Question about changes introduced by erratum 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, 21 Mar 2020 23:25:19 -0000 Hello DMARC working group, I am going through the changes between RFC7601 and RFC8601 and try to understand the implication of the change introduced by erratum 5435. The new resinfo definition uses 1*propspec, that is, by my understanding of [1] and [2], potentially multiple consecutive propspecs without obvious delimiters. The beginning of a ptype and the end of a pvalue have no mandatory CFWS, so from my understanding, a verifier could construct a valid authres-header-field that is cumbersome to parse. I will refer to the "ptype.property" part of a propspec as its "key". The spf method defines smtp.helo and smtp.mailfrom. RFC8601, RFC7601 and RFC7001 have only examples of the form smtp.mailfrom=domain-name. However, RFC7208 shows a local-part@domain-name form in [3], so I must assume a parser for an RFC8601 resinfo needs to recognize both forms. So consider > spf=pass smtp.mailfrom=x.y.zsmtp.helo=a.b This is "clearly" - smtp.mailfrom = x.y.z - smtp.helo = a.b It seems that a 10 character lookahead is sufficient, as long as we are in the domain-name case. However, with > spf=pass smtp.mailfrom=x.y.zsmtp.helo=a.b@c.de the previous "cut" between x.y.z and smtp.helo is no longer valid, as we have a single smtp.mailfrom with - "x.y.zsmtp.helo=a.b" as the local-part, and - "c.de" as the domain-name. I see some issues: 1. The lookahead for the "@" is unbounded. 2. RFC8601 does not (that I am aware of) prohibit duplicate keys among multiple propspecs. They may be either completely redundant, i.e. "k1=v1 k1=v1 ..." or contradicting/overwriting each other, i.e. "k1=v1 k1=v2 ...". Without a delimiter between the propspecs, it seems even impossible to parse them unambiguously. 3. I believe that a parser for potentially non-separated propspecs would be ugly. Did I overlook or misunderstand something? Would you consider a parser RFC8601 compliant if it was only able to parse the "benevolent" forms of an authres header? Regards Damian [1] https://www.rfc-editor.org/rfc/rfc5234 [2] https://www.rfc-editor.org/rfc/rfc5234#section-3.1 [no "implicit specification of linear white space"] [3] https://www.rfc-editor.org/rfc/rfc7208#section-9.2 > But in answer to your question: dmarc@ietf.org, since RFC8601 is from the dmarc WG. [...] >> I have a question about a change in an RFC introduced by a specific >> erratum (5435). Is this the right list to ask such question? From nobody Sat Mar 21 18:04:09 2020 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 3F6353A08AD for ; Sat, 21 Mar 2020 18:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Nmk+PsLf; dkim=pass (1536-bit key) header.d=taugh.com header.b=dwePkSo3 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 drQvGFeTS9lj for ; Sat, 21 Mar 2020 18:04:07 -0700 (PDT) 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 B939D3A08AC for ; Sat, 21 Mar 2020 18:04:06 -0700 (PDT) Received: (qmail 32307 invoked from network); 22 Mar 2020 01:04:04 -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=7e31.5e76b984.k2003; bh=qJp4yIbxTspOwTe1JqrwBgCk22dpEOcsSLau3Nil7Lw=; b=Nmk+PsLf7x6uvz+TZLSPaTuRDsKcsOIhUUU8AkcaL2y2jEt5Keah5W642C7T/v29AoEXXEERkEu1smtUBv94aec7CF6WVEgUfwYGCBcJM9/bdRWsdX2iNyPL/rl327m/905N6fgmkiAdCc0lj8qP3RG43mXCCarIoXWP0HJ5f4QoElW9nKLY6tyZIl/etj8rzNhqmOqxc2U0c1kZdziQxZB03Fj67k41GyC6CSeIAGW4aln58YSVzHDnPhWVqg41 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=7e31.5e76b984.k2003; bh=qJp4yIbxTspOwTe1JqrwBgCk22dpEOcsSLau3Nil7Lw=; b=dwePkSo387qL2DSAlr2Z3dS6F7TJSnOOez4+/rK7yWK0RdoIIrt7rbSLQBbrkpwxzVIVaCko2yzjT7TzsRLAcMsyRpXBy1hAMOruV62HFjO6WjNISjBEgEzCM11UE2B78E7+HDufiA7dOcyGcCS0mGB2NtFILdSRrsXY9asTmSCjIytRfRT1A8+OSKqRqrkmYFnf8GEI8BW2UifS++grfeekIJbObTmCzvyJp6SDOAMBI4wCaAfUnx1rjd+A8w+B 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 ESMTP via TCP6; 22 Mar 2020 01:04:04 -0000 Received: by ary.qy (Postfix, from userid 501) id 7053C165D622; Sat, 21 Mar 2020 21:04:04 -0400 (EDT) Date: 21 Mar 2020 21:04:04 -0400 Message-Id: <20200322010404.7053C165D622@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de 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] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 01:04:08 -0000 In article you write: >Hello DMARC working group, > >I am going through the changes between RFC7601 and RFC8601 and try to >understand the implication of the change introduced by erratum 5435. >The new resinfo definition uses 1*propspec, that is, by my understanding >of [1] and [2], potentially multiple consecutive propspecs without >obvious delimiters. ... It says: resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] [ CFWS 1*propspec ] I think both the erratum and RFC 8601 are wrong, and it should say: resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 1*( CFWS propspec ) Every implementation I know puts space between multiple propspec's which the current syntax wouldn't allow >The spf method defines smtp.helo and smtp.mailfrom. RFC8601, RFC7601 and >RFC7001 have only examples of the form smtp.mailfrom=domain-name. >However, RFC7208 shows a local-part@domain-name form in [3], so I must >assume a parser for an RFC8601 resinfo needs to recognize both forms. So >consider That's a mistake in the examples in Appendix B. The example at the bottom of page 21 is correct -- the value for smtp.mailfrom is a mailbox, not a domain name. R's, John From nobody Sat Mar 21 18:31:31 2020 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 B4FE43A08FF for ; Sat, 21 Mar 2020 18:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nWqX4B1gLxpw for ; Sat, 21 Mar 2020 18:31:28 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 1B4523A08FE for ; Sat, 21 Mar 2020 18:31:27 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id a63so6506790vsa.8 for ; Sat, 21 Mar 2020 18:31:27 -0700 (PDT) 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=tdQZZNttqfY5DaooNWxXRzQb7QkFFecT5jsLtga3mqI=; b=E5ZuvRHjd+Xy3QUeM7KeZNMsFa9Y2e0LqS0iZJSozsT2zJV1+E9dqI3GKbe3Vi5XM1 uKZaNBRsGmJBxm1UVD8xsMUtAK31lkCkviEB86BCyHTcHBfsL0ba3ms5ce0RkLzGCZy9 6GRstY1r7r150B4LROBf/aOsRxrgI9IMjegYtNkIdWvQq36gNPIfHyTK37cDxX4oK6H+ vHW9ET3m/c2nbG9BA2yZAZERcIH0ye1dmwIAIzBJ8rLlMbdkqXyDjHkbPDYFH30IFbtM vrx1X3jsY5E+ExlOI5gQEVq0XZ8xeRLJ0lTfaOo/xuZT6lE+KwMRDueK4JV1sXU9Ppq5 5EJQ== 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=tdQZZNttqfY5DaooNWxXRzQb7QkFFecT5jsLtga3mqI=; b=sizLJjtJo9LPHYd7aGUHv1Xe8Rx6pkUj9kzoTU7erJpyyRFzvLhcrUQ/9zL12aN+fN spX5m+2EeuxisIZiN7BQDsK1LEZTr6FGq4gFaESU2LxdtLn2w5oQXDboYN6FqiiewXhH 33vDL6ezMLMkXDtaRgb+TOTIv2De+kbKJ+rROiLnfZ4qGQlbj/9i5KZhPGSFVzOwqYnO zkuiqpX4O0b82eL3URHsxOGMQIavIcCh6lN68l8mnigkS+Nl6I4bP4oX/2Nc7V3K9OHE pxWVZb5hA7zO0rGJM5pPfrYAkRNwiqNICwoTKwKf41CNvVPyc9b9EWJxff9oamkg9hsS 6qVw== X-Gm-Message-State: ANhLgQ2WyiNrI4ZeTMmMsTqrw2KLd8p7spwamsTUeArOQaJ0LFZETXXe 63VJarDpq3kAOQJlFweTCGNs6zf2hyb4ct0gKoRa1yiQ X-Google-Smtp-Source: ADFU+vskc1ucJIBkudPUpIDQXFC5B+A9pMysPT10DTdhT6wGjiu8EstWPW6zHGcaLj6lSUv6D65twbUKaW5jpMEsaxk= X-Received: by 2002:a67:c10f:: with SMTP id d15mr11228359vsj.7.1584840686930; Sat, 21 Mar 2020 18:31:26 -0700 (PDT) MIME-Version: 1.0 References: <20200319011703.E1A70163EB3F@ary.qy> In-Reply-To: <20200319011703.E1A70163EB3F@ary.qy> From: "Murray S. Kucherawy" Date: Sat, 21 Mar 2020 18:31:14 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002b8e7b05a1677ac3" Archived-At: Subject: Re: [dmarc-ietf] Summary comments 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: Sun, 22 Mar 2020 01:31:30 -0000 --0000000000002b8e7b05a1677ac3 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 18, 2020 at 6:17 PM John Levine wrote: > >The issue PSD is attempting to address is mail sent as a nonexistent > >subdomain. For example, irs.gov doesn't have a subdomain called > >auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could > send > >email as msk@auditors.irs.gov without limitation. ... > > I have less sympathy for that argument. I do a hard reject of any > mail with a nonexistent bounce address which I don't think is unusual. > > PSD as I understand it is to address the same issue the organizational > domain does, but a level up, in a group of organizations that have > some administrative connection. The issue is people who publish A and > MX records without covering DMARC records. They're not supposed to do > that but they do, and PSD is one way of figuring out who needs to fix what. > Sorry, yes, my example was faulty. -MSK --0000000000002b8e7b05a1677ac3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 18, 2020 at 6:17 PM John Levi= ne <johnl@taugh.com> wrote:
>The issue PSD is attempting to address is mail sent as a non= existent
>subdomain.=C2=A0 For example, irs.gov doesn't have a subdomain called
>auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could send<= br> >email as msk@= auditors.irs.gov without limitation. ...

I have less sympathy for that argument.=C2=A0 I do a hard reject of any
mail with a nonexistent bounce address which I don't think is unusual.<= br>
PSD as I understand it is to address the same issue the organizational
domain does, but a level up, in a group of organizations that have
some administrative connection.=C2=A0 The issue is people who publish A and=
MX records without covering DMARC records.=C2=A0 They're not supposed t= o do
that but they do, and PSD is one way of figuring out who needs to fix what.=

Sorry, yes, my example was faulty.

-MSK
=
--0000000000002b8e7b05a1677ac3-- From nobody Sat Mar 21 18:32:43 2020 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 8194F3A08C2 for ; Sat, 21 Mar 2020 18:17:29 -0700 (PDT) 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, 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 CXzmZU-w4his for ; Sat, 21 Mar 2020 18:17:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6983A08C1 for ; Sat, 21 Mar 2020 18:17:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67235F4071C; Sat, 21 Mar 2020 18:17:21 -0700 (PDT) To: superuser@gmail.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, superuser@gmail.com, seth@sethblank.com, tjw.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@johnlevine.com, dmarc@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200322011721.67235F4071C@rfc-editor.org> Date: Sat, 21 Mar 2020 18:17:21 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 21 Mar 2020 18:32:42 -0700 Subject: [dmarc-ietf] [Technical Errata Reported] RFC8601 (6026) 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: Sun, 22 Mar 2020 01:17:30 -0000 The following errata report has been submitted for RFC8601, "Message Header Field for Indicating Message Authentication Status". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6026 -------------------------------------- Type: Technical Reported by: John Levine Section: 2.2 Original Text ------------- resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] [ CFWS 1*propspec ] Corrected Text -------------- resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] *( CFWS propspec ) Notes ----- When there is more than one propspec, they are separated by spaces. Every implementation I know puts in the spaces. This was correct in RFC 7601, but see unconfirmed erratum 5435 which introduced the mistake. While we're at it, take out the [CFWS] at the end of the definition of pvalue which is redundant and confusing. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8601 (draft-ietf-dmarc-rfc7601bis-06) -------------------------------------- Title : Message Header Field for Indicating Message Authentication Status Publication Date : May 2019 Author(s) : M. Kucherawy Category : PROPOSED STANDARD Source : Domain-based Message Authentication, Reporting & Conformance Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Sat Mar 21 18:32:47 2020 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 521563A08C8 for ; Sat, 21 Mar 2020 18:21:35 -0700 (PDT) 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, 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 79rUVpdoNXrA for ; Sat, 21 Mar 2020 18:21:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719813A08CB for ; Sat, 21 Mar 2020 18:21:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A8EC1F4071C; Sat, 21 Mar 2020 18:21:26 -0700 (PDT) To: superuser@gmail.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, superuser@gmail.com, seth@sethblank.com, tjw.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@johnlevine.com, dmarc@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200322012126.A8EC1F4071C@rfc-editor.org> Date: Sat, 21 Mar 2020 18:21:26 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 21 Mar 2020 18:32:42 -0700 Subject: [dmarc-ietf] [Technical Errata Reported] RFC8601 (6027) 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: Sun, 22 Mar 2020 01:21:36 -0000 The following errata report has been submitted for RFC8601, "Message Header Field for Indicating Message Authentication Status". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6027 -------------------------------------- Type: Technical Reported by: John Levine Section: Appendix B Original Text ------------- spf=pass smtp.mailfrom=example.net Corrected Text -------------- spf=pass smtp.mailfrom=sender@example.net Notes ----- This error appears three places in Appendix B. smtp.mailfrom takes a mailbox, not a domain name. The example in section 2.7.4 at the bottom of page 21 is OK. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8601 (draft-ietf-dmarc-rfc7601bis-06) -------------------------------------- Title : Message Header Field for Indicating Message Authentication Status Publication Date : May 2019 Author(s) : M. Kucherawy Category : PROPOSED STANDARD Source : Domain-based Message Authentication, Reporting & Conformance Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Sun Mar 22 03:34:58 2020 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 D01C23A0816 for ; Sun, 22 Mar 2020 03:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 Jkna37EFGORP for ; Sun, 22 Mar 2020 03:34:55 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0090B3A0814 for ; Sun, 22 Mar 2020 03:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id :references:from:from:subject:subject:x-amavis-category; s= dkim01; t=1584873292; x=1586687693; bh=KxX18pWFRY61fQv3ysMgPYrSD OvEX+uyt+m/N/oXrts=; b=NMmAjGG7I3UBPY3Mz0i7SMeW5SPWMtt4p8ufidL6Y dCKukz1Wh7t9Rn5TNKNBNhRN3kQ2kPDepzupuhP3UQaSTchbHhVP31cmhKRMNg4R C6tP8jzFz46DDS97q1KLk9OFeZg98Uo+xbgs/sD6nQNGi3w3Mv7skEZt5IBcILN3 vU= X-Amavis-Category: scalar.arcsin.de; category=CleanTag From: Damian Lukowski To: John Levine , dmarc@ietf.org References: <20200322010404.7053C165D622@ary.qy> Message-ID: Date: Sun, 22 Mar 2020 11:35:18 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 10:34:57 -0000 >> Every implementation I know puts space between multiple propspec's >> which the current syntax wouldn't allow > my understanding was that RFCs decide whether an implementation is > incorrect or in the case of a series, not up-to-date. If the authors > decided to update the RFC instead, then I'd be happy of course. Also please note that spaces between propspecs are not against RFC8601 - they would use the optional CFWS at the end of a pvalue. It's just the fact that they are not mandatory what bothered me. From nobody Sun Mar 22 07:50:54 2020 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 4681B3A07BA for ; Sun, 22 Mar 2020 07:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=HsTSLd49; dkim=pass (1536-bit key) header.d=taugh.com header.b=eIdn/rlb 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 svCxfo_Zr3RM for ; Sun, 22 Mar 2020 07:50:47 -0700 (PDT) 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 355793A0814 for ; Sun, 22 Mar 2020 07:50:45 -0700 (PDT) Received: (qmail 57290 invoked from network); 22 Mar 2020 14:50:38 -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=dfc8.5e777b3e.k2003; bh=VrZBuEZdoIzwVR8OLi4RVoki7E+q6tepFbSrqEg/MDg=; b=HsTSLd49KmacBDyqIkvZv3yNqydUUJY0kW9DAMhzqoofoI7nhlJnG8BFXlCdznedOpi7oYoB0E1ofbBXGG20IDI0Yl+l1R8T9Q/btWi11n2EHL1NZk2X44kIh0TxgtWZ0U2ljfeQ9ATlrlv7/kvaHB3nLAjwFOC/PcQXXjMPoWWrUKjEhcVI3+lVgDUPsg5GWq8yS7rs9tsr7wvFxFjnjzHWso5nmEh3CYdCi9okDir0hCLR0LzGQLDbeVxbNRW+ 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=dfc8.5e777b3e.k2003; bh=VrZBuEZdoIzwVR8OLi4RVoki7E+q6tepFbSrqEg/MDg=; b=eIdn/rlbal8kAHyDXtosSRNXtzDRMZ0X3Lc81wX/VyXzxXxv682h8yyHahQsTUfIZQJCHIkV2vHqusV4/6keL5fw38n1kUVtub5k/9KvLfZQhAcDTMSNjtgDBqJCpzkVus9xPfCgripb3V+/rWCOJHGC/yqIPNgPraCL3AlJtZDVtMmihVP+kOS7llnvdZrjvqztVKzBNITyZB63LX9WlCCUZeT5KohHh5egituDmQ2baY3zzTEiCdN2Dv30yJb5 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 ESMTP via TCP6; 22 Mar 2020 14:50:38 -0000 Received: by ary.qy (Postfix, from userid 501) id 736F616607CE; Sun, 22 Mar 2020 10:50:37 -0400 (EDT) Date: 22 Mar 2020 10:50:37 -0400 Message-Id: <20200322145038.736F616607CE@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de 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] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 14:50:53 -0000 In article you write: >>> Every implementation I know puts space between multiple propspec's >>> which the current syntax wouldn't allow >> my understanding was that RFCs decide whether an implementation is >> incorrect or in the case of a series, not up-to-date. If the authors >> decided to update the RFC instead, then I'd be happy of course. In general you're right, but it sometimes happens that the RFC has mistakes and what it says is not what the WG intended. In this case I'm quite sure that the intent is that spaces between propspecs are required and the ABNF in 8601 is wrong. Erratum 5435 misunderstood how ABNF works and somehow we all missed that. If you look through the archives of the WG you'll see that 8601 is intended to be a compatible update to 7601, and as you noted the ABNF change is definitely not compatible. R's, John From nobody Sun Mar 22 08:21:36 2020 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 1882F3A07DF for ; Sun, 22 Mar 2020 03:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 19nrsY0YDPi8 for ; Sun, 22 Mar 2020 03:06:56 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360333A07BA for ; Sun, 22 Mar 2020 03:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1584871611; x=1586686012; bh=DPTyc+YF+2TavpcsnBwclnW3pB9asD1Cx36 hqiOcD5E=; b=PKUz5ZPEPCCH6BcU4Jj6ocYLz75MaQp0rFMoBeBHQjSIOiMmZxz poG/C0OLjRKWS/60RVfnhi3XgndWVW+nxpo4ArWkP6IBx8mzTyeqKt5hZzdmouAs FeDPJUx08arvxUhjbFaWEOTdWY++dEt6VLRZuGInrDaQJNmyayYpMN1g= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: John Levine , dmarc@ietf.org References: <20200322010404.7053C165D622@ary.qy> From: Damian Lukowski Message-ID: Date: Sun, 22 Mar 2020 11:07:17 +0100 MIME-Version: 1.0 In-Reply-To: <20200322010404.7053C165D622@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2020 08:21:35 -0700 Subject: Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 10:06:59 -0000 Hi, > resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] > [ CFWS 1*propspec ] > > I think both the erratum and RFC 8601 are wrong, and it should say: > > resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] > 1*( CFWS propspec ) > > Every implementation I know puts space between multiple propspec's > which the current syntax wouldn't allow my understanding was that RFCs decide whether an implementation is incorrect or in the case of a series, not up-to-date. If the authors decided to update the RFC instead, then I'd be happy of course. > That's a mistake in the examples in Appendix B. The example at the > bottom of page 21 is correct -- the value for smtp.mailfrom is a > mailbox, not a domain name. I assume you mean > auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example I didn't consider this example relevant for the spf-case. For the auth-case, the right-hand-side is defined in [AUTH] as mailbox and there are no A-R examples that would state otherwise. [SPF] on the other hand has an A-R example that is domain-name only, so I assumed that smtp.mailfrom in spf context was more loosely defined via RFC7001's pvalue (that is, with the optional local-part@). Damian From nobody Sun Mar 22 08:44:42 2020 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 5A6193A0890 for ; Sun, 22 Mar 2020 08:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=L3vkydPx; dkim=pass (1536-bit key) header.d=taugh.com header.b=VJVIvZU6 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 bn_Dm4Y43eRj for ; Sun, 22 Mar 2020 08:44:39 -0700 (PDT) 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 B180B3A088D for ; Sun, 22 Mar 2020 08:44:39 -0700 (PDT) Received: (qmail 68400 invoked from network); 22 Mar 2020 15:44:38 -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=10b2e.5e7787e6.k2003; bh=eH4hCFv2ZrM42csNYLO+E2otG7qcQFPkVL9M67kSXRg=; b=L3vkydPx3zRnNYJKGeKl2fnDERjclAOQvJuG5U8OEuHtU/lboZl/TkM858FKXzefuXTbxegvtVGk0UJjWeofIiQqGpbvmY3J5/cE8FKHSFxxrtVJQEpKt86+vUurW8ULC955aoCnjzE1cWicLN9uPlkcfJT/f2u2lcR4Vsx53bfmK6UZLHrfvinhZ8uF7zRPLbS1TQoBFsnh7CojZ1rPXoirODqeEvlqrpanor8EMBoOX+KghLSggaz9/yZjSBV/ 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=10b2e.5e7787e6.k2003; bh=eH4hCFv2ZrM42csNYLO+E2otG7qcQFPkVL9M67kSXRg=; b=VJVIvZU69bON3oWWV9HHqk8JYhv5iuT1Xp+r2CcS248DpvdL/2dgRKdgV+OOAeJgnW22MCH0Jm6VMKMiGn+icwI0fB6B7ie/Jyx4ZXquT6wrq47RbKYO6gNqe6xykaXLH1j+MvBXq9jH1Xlk8+hDEjRxaD8ERMsIHF4dMfuZ2DqrO+Km36ctK+eMV9j+v0rstz+a5luIsaHows3VeqeEuKC+wbZKebXGF+/fP7gd395TgqqF6VooOjBTuv5aLQ2u 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 ESMTP via TCP6; 22 Mar 2020 15:44:38 -0000 Received: by ary.qy (Postfix, from userid 501) id 14E02166129A; Sun, 22 Mar 2020 11:44:37 -0400 (EDT) Date: 22 Mar 2020 11:44:37 -0400 Message-Id: <20200322154438.14E02166129A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de 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] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 15:44:42 -0000 In article you write: >.... [SPF] on the other hand >has an A-R example that is domain-name only, so I assumed that >smtp.mailfrom in spf context was more loosely defined via RFC7001's >pvalue (that is, with the optional local-part@). I'm pretty sure the example is wrong, and was copied verbatim from wrong examples going back to RFC5451. RFC8601 sec 2.7.2 refers to RFC 7208 for "mailfrom". RFC 7208 sec 1.1.3 says that the MAIL FROM, which I whink we can assume is the same thing, is the RFC5321.MailFrom from RFC 5598. RFC 5598 says that's a mailbox, not a domain name. gain, if you look at the existing implementations, they put the address in spf smtp.mailfrom, not just the domain name. R's, John PS: I have always found it frustrating that I have to chase through a dozen documents to find the syntax of A-R. I understand the desire not to try to keep two copies of definitions in sync, but as we've seen, that doesn't always lead to the result you want. From nobody Sun Mar 22 12:34:24 2020 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 8618F3A0862 for ; Sun, 22 Mar 2020 12:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 zSwPJIU0aQ7Q for ; Sun, 22 Mar 2020 12:33:50 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C655B3A085B for ; Sun, 22 Mar 2020 12:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1584905624; x=1586720025; bh=4bycgEnM8XKjEohaK6cjjJGhBhzxMnbVFLB AfOr9XBw=; b=a6uP5+E8xN5CTSYTFfNxzNxo8n9QQrLhDimk8Q06i34tDWk1zkx YO2zrRyspJ4gZkfW6WlpZCVX5uGbCF9awAB4CSnEhNUdoHs819SW997YTyXUGEfA TcY9TESZcMafEcqrcvftL/P83FPKY9VJdF4H//fMXxbhKb1Ciqv5d82k= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: John Levine , dmarc@ietf.org References: <20200322154438.14E02166129A@ary.qy> From: Damian Lukowski Message-ID: <09ec8dda-7165-fae8-f8e1-f88561085e47@arcsin.de> Date: Sun, 22 Mar 2020 20:34:11 +0100 MIME-Version: 1.0 In-Reply-To: <20200322154438.14E02166129A@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 19:33:53 -0000 > RFC8601 sec 2.7.2 refers to RFC 7208 for "mailfrom". RFC 7208 sec 1.1.3 > says that the MAIL FROM, which I whink we can assume is the same thing, > is the RFC5321.MailFrom from RFC 5598. RFC 5598 says that's a mailbox, > not a domain name. Those definitions are too confusing for me. RFC5598 says > RFC5321.MailFrom is the address in the SMTP "Mail From" command So is RFC5321.MailFrom the Reverse-Path from RFC5321, or only the Mailbox part of a Reverse-Path? I would expect it to be the full Reverse-path, because > RFC5321.Return-Path: Set by - Originator > The MDA records the RFC5321.MailFrom address into the > RFC5321.Return-Path field. and a Return-Path field usually contains "<" ... ">", so it cannot be a plain Mailbox. But then the term "MAIL FROM" in > As such, throughout this document the term "MAIL FROM" will be used, > which is defined as the RFC5321.MailFrom (reverse-path) identity > described in [RFC5598]. cannot be identical to RFC5321.MailFrom, because if it were, we would have smtp.mailfrom = "MAIL FROM" = RFC5321.MailFrom = "<" ... ">", which is not given by the examples. Another possibility to interpret the quote is that one obtains the "MAIL FROM" by picking "the" identity out of the RFC5321.MailFrom. But there are two sensible identities defined in RFC5598 that one could pick: The mailbox or the domain name. > The forms of identity used by Internet Mail are: mailbox, domain > name, [...] By the way, an RFC5321 mailbox allows address-literals which are not covered by the right hand side of RFC8601's pvalue, and one cannot use the left hand side because of > If the value portion of a "pvalue" construction identifies something > intended to be an email identity, then it MUST use the right-hand > portion of that ABNF definition. From nobody Sun Mar 22 12:41:38 2020 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 C535E3A0870 for ; Sun, 22 Mar 2020 12:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=mAW6kM/W; dkim=pass (1536-bit key) header.d=taugh.com header.b=Oca0qNie 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 4UngiIK7-oxs for ; Sun, 22 Mar 2020 12:41:34 -0700 (PDT) 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 1835C3A086F for ; Sun, 22 Mar 2020 12:41:33 -0700 (PDT) Received: (qmail 9519 invoked from network); 22 Mar 2020 19:41:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=252b.5e77bf6b.k2003; i=johnl-iecc.com@submit.iecc.com; bh=CLDaIP4IadsIuouJLD0o+uD7RunX6YBoUgA+IqdgdIg=; b=mAW6kM/WtVOb+y3bHpkROEmz0yup15297rr9l+Ggk1lYtcZ7B5kdNI0DRjBVHJKz3HbEStcJ60uGskKk+uJ27Zr4AaVAPGzXS6vXp+NqmIG8oKir6VDQdU8RkIhsqDnE/rDgKU3DxbT91GGJzy3tBv6GixfzZmx1RSlx8Ft3hOU3laBWstey3lFroc7wkGqnooijMQUxo0nnT7F7Gk4my+ijd0OVYiQgvudg9M9plRKDpzdYOqvA8FQL8y0A4ZTF DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=252b.5e77bf6b.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=CLDaIP4IadsIuouJLD0o+uD7RunX6YBoUgA+IqdgdIg=; b=Oca0qNieZnCmc29lYUQ0kVSe49Y8fhl8PHFv4tFbVXWd86qCh/ObGiyB8EY4T1OaQgbF3kyKr3uMIFji7TLrylVUUjLK0cXwsOF8iWujiJVSKpPlp1AcTkII38XsUFTzbnVDUtqgXfFC2fNOd4pLTCP4f2D9xlgdhDkHKw1CgVW5lG/Io//8mH5JscKHeJpsKn7bmpsLc06oYPSkNalYF5DVhUA2ezyJ9igSXsWz7kRXiwQbeEVTuxo56LYvCzHP Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 Mar 2020 19:41:30 -0000 Date: 22 Mar 2020 15:41:30 -0400 Message-ID: From: "John R Levine" To: "Damian Lukowski" , dmarc@ietf.org In-Reply-To: <09ec8dda-7165-fae8-f8e1-f88561085e47@arcsin.de> References: <20200322154438.14E02166129A@ary.qy> <09ec8dda-7165-fae8-f8e1-f88561085e47@arcsin.de> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 19:41:36 -0000 >> RFC5321.MailFrom is the address in the SMTP "Mail From" command > > So is RFC5321.MailFrom the Reverse-Path from RFC5321, or only the > Mailbox part of a Reverse-Path? I would expect it to be the full > Reverse-path, because RFCs 2821 and 5321 say: Historically, the was permitted to contain more than just a mailbox; however, contemporary systems SHOULD NOT use source routing (see Appendix C). Source routes have been deprecated for 20 years. We can forget about them. > and a Return-Path field usually contains "<" ... ">", so it cannot be a > plain Mailbox. No, see RFC 2821 or 5321 sec 3.3. The reverse-path is what's between the brackets, which means it's a mailbox or it's empty. > By the way, an RFC5321 mailbox allows address-literals which are not > covered by the right hand side of RFC8601's pvalue, and one cannot use > the left hand side because of I haven't seen an address literal in non-spam mail for over a decade either. I'm pretty sure we can forget about them in A-R headers, too. R's, John From nobody Sun Mar 22 13:12:18 2020 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 11C333A03F5 for ; Sun, 22 Mar 2020 13:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 qitcRMFr6TwR for ; Sun, 22 Mar 2020 13:12:14 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8F53A02BD for ; Sun, 22 Mar 2020 13:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1584907930; x=1586722331; bh=GtyIvhuNvfNbuy+BaoMQmlXXLSCZ/btf84q Zw3Y5NYs=; b=BI+kYyVSQ0kojNdW6PLvV/RsndDDQ3B3M1gQZdsk5jklWkBz/eZ h6Vnsuf28vtdGSLXPNVol9WB4T/mcMYuzKO/m7v3gsZJEF4YqPUj8Cb1MbNsAqHC cBWjHpzkzQNSmoKKGkPhJxgrtDpAe2TJMZV8rJymwo83FCd173IQ5X/I= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: John R Levine , dmarc@ietf.org References: <20200322154438.14E02166129A@ary.qy> <09ec8dda-7165-fae8-f8e1-f88561085e47@arcsin.de> From: Damian Lukowski Message-ID: <59f7d02b-e15c-25e4-2955-ea44615886e3@arcsin.de> Date: Sun, 22 Mar 2020 21:12:37 +0100 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] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 20:12:17 -0000 > No, see RFC 2821 or 5321 sec 3.3.  The reverse-path is what's between > the brackets, which means it's a mailbox or it's empty. Ok, I guess I didn't expect to have to go through a layer of english while assembling a grammar from different sources, given that there was an ABNF rule with a matching name. Regards Damian From nobody Sun Mar 22 14:13:34 2020 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 C5A3A3A0857 for ; Sun, 22 Mar 2020 14:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=LXsPRgC8; dkim=pass (1536-bit key) header.d=taugh.com header.b=drWAiEHz 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 TKeSpXIg7lig for ; Sun, 22 Mar 2020 14:13:31 -0700 (PDT) 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 D125A3A0855 for ; Sun, 22 Mar 2020 14:13:30 -0700 (PDT) Received: (qmail 21792 invoked from network); 22 Mar 2020 21:13:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:content-id:user-agent; s=551e.5e77d4f8.k2003; i=johnl-iecc.com@submit.iecc.com; bh=kDL0Qm5+Syu89xpJ1mNdMJbkCnJC8xsVOIvnwWw9E3A=; b=LXsPRgC8GWTBc19+v/OzCaB25hnHku857hKQU+tbsiy+wlkrEaLpvm4z3tpnwQStWilJmLbwzcX3Ypk2+p20gVYjKnOC9F3vg+ciM69isa2GzqJDB+rU5+w8dgi0ciTUOpe1xlalydIFZIjnezuTwHLvDx3FMukDyLpUgrS228W/TJ6dqqvXDtLlD4lOGh3sMcpJRYYoESkvAbz5zAE3kWKa92zJKrZ4L4fj9re/QWeERTqa6WY2S0TkO9eCcU79 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:content-id:user-agent; s=551e.5e77d4f8.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=kDL0Qm5+Syu89xpJ1mNdMJbkCnJC8xsVOIvnwWw9E3A=; b=drWAiEHzOYYkC67hRy5DIz2OBAd3QbeEZ+87UZxPv+IDuwY0lMsNkqpZ8JTSld5Ytn5mB+kOufTD9sLNA/x8/VJuwTFaed54ROG8TU8tdmJvdzZt63g0y79WFiocBoqOeizCrBbmSVake2MiYT61v4MUqrRKA+3qLuLmBFvLG/IQizReq5wdzyzbB5l4VbaUOP86ZWET0ZxLFSYPNn02jbFOvF6WpR76qNajju2mrH0kvIv8RaiBuGd1fEIvT61t Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 Mar 2020 21:13:28 -0000 Date: 22 Mar 2020 17:13:28 -0400 Message-ID: From: "John R Levine" To: "Damian Lukowski" , dmarc@ietf.org In-Reply-To: <59f7d02b-e15c-25e4-2955-ea44615886e3@arcsin.de> References: <20200322154438.14E02166129A@ary.qy> <09ec8dda-7165-fae8-f8e1-f88561085e47@arcsin.de> <59f7d02b-e15c-25e4-2955-ea44615886e3@arcsin.de> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1347382827-1584909547=:16970" Content-ID: Archived-At: Subject: Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 21:13:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1347382827-1584909547=:16970 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: >> No, see RFC 2821 or 5321 sec 3.3.  The reverse-path is what's between >> the brackets, which means it's a mailbox or it's empty. > > Ok, I guess I didn't expect to have to go through a layer of english > while assembling a grammar from different sources, given that there was > an ABNF rule with a matching name. Figuring out the actual syntax of A-R is quite hard because there are so very many external references. Even the ABNF is tricky -- I had to stare at the definitions of resinfo and propspec and pvalue for quite a while to confirm that your interpretation was correct. A lot of people (not you) when reading RFC 5234 assume that there has to be only one way that the BNF can match a string. That's not true, ambiguous matches are allowed, and sometimes can make the ABNF simpler. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1347382827-1584909547=:16970-- From nobody Sun Mar 22 15:03:50 2020 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 166A53A08DD for ; Sun, 22 Mar 2020 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 2_sRB9t9v8-y for ; Sun, 22 Mar 2020 15:03:45 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27A73A08DA for ; Sun, 22 Mar 2020 15:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1584914620; x=1586729021; bh=OA+QMNPPz/JZr0LvQAilcZ5oGraNbyTokLa pjRgz8o8=; b=mkmimt5sRIphl8zj6f8+0A/nUg8OuPefOC1K4ORjhxItcobGxWp AV0Pee4Fi2VEC+ql2GIRRiVONaQzjyMj5rNZpkSJqptwuLo+Yg+sK92bZY0dyTf/ A1+fdDUIthHh/XRyGXX246ZUXx6LBGwIw4Xmfg0uMOMHr16PndUN5FHU= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: John R Levine , dmarc@ietf.org References: <20200322154438.14E02166129A@ary.qy> <09ec8dda-7165-fae8-f8e1-f88561085e47@arcsin.de> <59f7d02b-e15c-25e4-2955-ea44615886e3@arcsin.de> From: Damian Lukowski Message-ID: <45864cb6-c8b1-5e4d-6bea-fe2ba8cc089b@arcsin.de> Date: Sun, 22 Mar 2020 23:04:08 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum 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: Sun, 22 Mar 2020 22:03:48 -0000 Haha, I just found https://mailarchive.ietf.org/arch/msg/dmarc/FO6ImuO5jzr9ZvN6FcLAzMoH3-c/ Damian From nobody Sat Mar 28 03:39:35 2020 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 96AFD3A0924 for ; Sat, 28 Mar 2020 03:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 EgZRZbTQvqgp for ; Sat, 28 Mar 2020 03:39:31 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596513A0914 for ; Sat, 28 Mar 2020 03:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:mime-version:date:date:message-id:subject:subject :from:from:x-amavis-category; s=dkim01; t=1585391965; x= 1587206366; bh=6bFhLQnfneAy/oJy441mew/EYnqT36du57xXijq+mxc=; b=c PuczRZycvuiSBJV2Kgu5zStusMFGggBmqAR4VAGDW8hzTlouv6EGj7LSekIE3phL ahvZITtKpjIJaiBlO7UpKkl0bzpxseto+88ewk9XdAqZACf5CAi+ZVefsN1oarSE Tid1VVNHe+ETpIEUHKjInWbejEpI+c88YWqVWUo9rs= X-Amavis-Category: scalar.arcsin.de; category=CleanTag From: Damian Lukowski To: dmarc@ietf.org Message-ID: Date: Sat, 28 Mar 2020 11:39:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Definition of "value" in RFC8601 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, 28 Mar 2020 10:39:34 -0000 Hello, RFC8601 section 2.2 defines > authserv-id = value > ; see below for a description of this element > [...] > The "value" is as defined in Section 5.1 of [MIME], with > "quoted-string" updated as specified in [RFC6532]. [MIME] (RFC2045) section 5.1 > value := token / quoted-string > token := 1* or tspecials> The token is not said to be updated by [RFC6532] as is quoted-string, so by my interpretation non-ASCII cannot be used without quotes. If so, then current implementations of OpenDKIM and OpenDMARC are wrong or imcomplete, as they do not check for Non-ASCII AuthservID and produce headers like > Authentication-Results: öde; dkim=none; dkim-atps=neutral Is my understanding correct? Regards Damian From nobody Mon Mar 30 13:58:13 2020 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 A99B63A111C for ; Mon, 30 Mar 2020 13:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nuUe5tNKEtmG for ; Mon, 30 Mar 2020 13:58:11 -0700 (PDT) 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 07BC93A111B for ; Mon, 30 Mar 2020 13:58:10 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id s10so12023611vsi.9 for ; Mon, 30 Mar 2020 13:58:10 -0700 (PDT) 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=SxXgYFlQqMDnSWrYVh7iBByqxU3JUdY9AYRSx5+nNOI=; b=NgLj/ZToVs4/ATW5Is0i6Z5RxRpBexy0NAk3Pr1Z547X9VhVe4N3Nbr4TKlnfgCLi7 KM+59d0+4jnbae+ts0brC0v88tLGqVdK+PoKfwy0NwgdTzVxZXVud0pPWlrpBYruP1N6 5an2DT+mzQ9YckvHDJCI1wlLqQ71PaRRxugs7aY/lCenMeeGzkEXvxNv02m+T/Crbf1t 6KKLbUr1vFh7KBLP3IA3eavx2tXrE5FgWditT7f86skR1NX9LwXoj1hQaaX1/GMVcRX5 sNsseYMlSLpjZs+KrnvcmWvIDFhfGdiBrL/GNYvLyceSLyY/vVk0WUTZkcCX2JmkdaZp 8ikA== 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=SxXgYFlQqMDnSWrYVh7iBByqxU3JUdY9AYRSx5+nNOI=; b=B+okYMQ9CzygvpIvqDXt1Aptrwfb9m99isN1B/RLdXgmbgymWE8mr6nmmivthDgDYL t1p6IBAcN3ZlwmBAU72Z8UFXuEtbnN6Gc1nlrFgjIWbuRTdZXygvc/rSX2sy7Wav8zi0 nKo1EbZwgYbG9r/VTkiAsfIx9E1QxxoHxfFO1mUYvg0O/5Spox8+CaprIBJL4Kufcwvp zr0rvBL3s4QCJei65kblX3BQ/78NdAM38bH2m4RbPVSJd3cmDY+STVgEGKGzkEfvjddd 0sdw4tESq4lzIpmn+j4fid2HmYfZ9XpfnR26N6rEgGB++41o2+NgUXRlh3Sub0p80nMq Yj/g== X-Gm-Message-State: AGi0PuZ3rFSWf0v+AZIP6cjKYAXlXSCWSNXPIE2zTXYaGqImSI6/T20b XovHhlhVtoqPN5pkcEpHd3CZB8+Yajj618Nq1mWz5sE= X-Google-Smtp-Source: APiQypIFgueES5DtGc01WBlKXcWLNPCkmYfeY4GV/e1lUjY7olOc9dl7cBFf5Sp0g7VojMwXBG9tuTRosGifHgnHa+k= X-Received: by 2002:a67:2ed2:: with SMTP id u201mr10173517vsu.209.1585601889478; Mon, 30 Mar 2020 13:58:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Mon, 30 Mar 2020 13:57:57 -0700 Message-ID: To: Damian Lukowski Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000061140b05a218b5fc" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 30 Mar 2020 20:58:13 -0000 --00000000000061140b05a218b5fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hmm, we didn't include this in RFC 8616 either, I could imagine that it should be punycoded also, though it really depends on whether in 6532 or 5322. Brandon On Sat, Mar 28, 2020 at 3:39 AM Damian Lukowski wrote: > Hello, > > RFC8601 section 2.2 defines > > > authserv-id =3D value > > ; see below for a description of this element > > [...] > > The "value" is as defined in Section 5.1 of [MIME], with > > "quoted-string" updated as specified in [RFC6532]. > [MIME] (RFC2045) section 5.1 > > > value :=3D token / quoted-string > > token :=3D 1* > or tspecials> > > The token is not said to be updated by [RFC6532] as is quoted-string, so > by my interpretation non-ASCII cannot be used without quotes. > > If so, then current implementations of OpenDKIM and OpenDMARC are wrong > or imcomplete, as they do not check for Non-ASCII AuthservID and produce > headers like > > > Authentication-Results: =C3=B6de; dkim=3Dnone; dkim-atps=3Dneutral > Is my understanding correct? > > Regards > Damian > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000061140b05a218b5fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm, we didn't include this in RFC 8616 either, I coul= d imagine that it should be punycoded=C2=A0also, though=C2=A0it really depe= nds on whether in 6532 or 5322.

Brandon

<= div class=3D"gmail_quote">
On Sat, Mar= 28, 2020 at 3:39 AM Damian Lukowski <r= fc@arcsin.de> wrote:
Hello,

RFC8601 section 2.2 defines

> authserv-id =3D value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; see below for a descr= iption of this element
> [...]
> The "value" is as defined in Section 5.1 of [MIME], with
> "quoted-string" updated as specified in [RFC6532].
[MIME] (RFC2045) section 5.1

> value :=3D token / quoted-string
> token :=3D 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or tspecials>

The token is not said to be updated by [RFC6532] as is quoted-string, so by my interpretation non-ASCII cannot be used without quotes.

If so, then current implementations of OpenDKIM and OpenDMARC are wrong
or imcomplete, as they do not check for Non-ASCII AuthservID and produce headers like

> Authentication-Results: =C3=B6de; dkim=3Dnone; dkim-atps=3Dneutral
Is my understanding correct?

Regards
=C2=A0Damian

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000061140b05a218b5fc-- From nobody Mon Mar 30 14:08:31 2020 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 BA3AA3A124C for ; Mon, 30 Mar 2020 14:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 i-1Q76IxxbA0 for ; Mon, 30 Mar 2020 14:08:29 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE70F3A124A for ; Mon, 30 Mar 2020 14:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585602505; x=1587416906; bh=UiUNGBmAsWtg964tNU0OecVZCL60YntbZG2 JiSNunz4=; b=DrZPuGle0TJX23tIwf3REL9F5A8cvSwqQboXfEKVtmGG9aMAnDv O3V99PlweBO7Yju+wPEYX3uneJA1dGG4+Iq6WipVx2wX476a4esXbnkHPDs4WrMw dHUWckh5oUOma97aq9WF1hktCgS6oWBkaMSTcl8/5o79/ZplSl1TD4tE= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: From: Damian Lukowski Message-ID: <7b6dc3b0-37a9-3e20-00e3-420216c6c882@arcsin.de> Date: Mon, 30 Mar 2020 23:09:03 +0200 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] Definition of "value" in RFC8601 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, 30 Mar 2020 21:08:31 -0000 > Hmm, we didn't include this in RFC 8616 either, I could imagine that it > should be punycoded also, though it really depends on whether in 6532 or > 5322. Why punycoded? Section 2.5 does not specify that it needs to be a domain name, even though it usually is. From nobody Mon Mar 30 14:14:07 2020 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 375043A133B for ; Mon, 30 Mar 2020 14:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cPJEIA4H4CWo for ; Mon, 30 Mar 2020 14:14:05 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 CD7C93A133A for ; Mon, 30 Mar 2020 14:14:04 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id m18so6865153uap.9 for ; Mon, 30 Mar 2020 14:14:04 -0700 (PDT) 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=6SKY+o2HWha1Wxak0FhN1QDB3VV5zLMVwelawMjDLsg=; b=XRNcXl4q+5HLUiLZPfA3YLU7uHEOMv87wE0djA4trdhDvJdbDG0eIrJQ6YCgcATW21 VJowEJ/i423pbKirncc4KSYwZmXIZxTF0FWyGdJLUWXyPigdGSEYNdvPeuK5Z3qadEFV xQtyihU4ZJoms+AUJlETWIPh9UYoV7AH2DPXTgh3fDbk6WkLuiucDJqk/c69zfv217Wh DHEO08O2Dm0NHXB0Ii3zuqZKl1uylaBvn7IrBq1smA6iIQQH3bDteBcW1v3UXd7RAQVu mbKs6ZK9+2XiGsAS9kYjWISbfxCmrShVXgtkcLvyviO9T1g+ztjgULnbFar4uC1oXW8s KkNA== 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=6SKY+o2HWha1Wxak0FhN1QDB3VV5zLMVwelawMjDLsg=; b=MAxFbOiU3aIn0KsnZsF6LHJ5inu+c3fJsait5U30xE82PT4yYpuAVaP7hLUmvZoqC4 FW+1NbOu93QqYwuVzGx7l6oAp3CCb9audnwXBAgtzfkxT9qVWUPf+SznjNdTFDu34E6d igMXXgNK5awboS0r6W8VNyFOm15R4DQGNM6a1mHSyODq6EJEPmV3DQsMtbYbu1O25FLf Sp8l438ShXdY0fB+OjeOAA8caFiUkVZ6k78E4SHT5VaaEQ91De6DFzkv2bydvalR2LSR qCykwYqW/wkFASUz52BQ2RspFGgfTKp91soHe4feIJmO8uiTQPsrBsg3XEhzsufqh0eo KWtw== X-Gm-Message-State: AGi0PuYM+XXcoChHisfVNwlwILcAbmtF7KJQcguOnvOwpU2Omi0avB/6 7eEsPJRORJ4x1g4qU9kQEcYqH0qw7QI9Nql/eleRTCo= X-Google-Smtp-Source: APiQypKc3TC5+MK37flD3z2uKdXOvUKd9nQiV2fWdjpepqdT4VBPkjTnXismA9hSVOTLycqqHh35+kZAJYpyLgPp43k= X-Received: by 2002:ab0:750c:: with SMTP id m12mr9269548uap.31.1585602843382; Mon, 30 Mar 2020 14:14:03 -0700 (PDT) MIME-Version: 1.0 References: <7b6dc3b0-37a9-3e20-00e3-420216c6c882@arcsin.de> In-Reply-To: <7b6dc3b0-37a9-3e20-00e3-420216c6c882@arcsin.de> From: Brandon Long Date: Mon, 30 Mar 2020 14:13:50 -0700 Message-ID: To: Damian Lukowski Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003cab2905a218ee4e" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 30 Mar 2020 21:14:06 -0000 --0000000000003cab2905a218ee4e Content-Type: text/plain; charset="UTF-8" if your admd is an IDN, and you had to include that in 5322, then specifying to do so in punycode would make sense. Just including it in double quotes in a 5322 message would not be correct, so then you're down to which mechanism to use, I don't think 2045-style would be correct... or 2231. But yes, as its not specified as a domain or domain-like, it would be odd to specify a domain encoding. Brandon On Mon, Mar 30, 2020 at 2:08 PM Damian Lukowski wrote: > > Hmm, we didn't include this in RFC 8616 either, I could imagine that it > > should be punycoded also, though it really depends on whether in 6532 or > > 5322. > Why punycoded? Section 2.5 does not specify that it needs to be a domain > name, even though it usually is. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000003cab2905a218ee4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
if your admd is an IDN, and you had to include that in 532= 2, then specifying to do so in punycode would make sense.

Just including it in double quotes in a 5322 message would not be correct= , so then you're down to which mechanism to use, I don't think 2045= -style would be correct... or 2231.

But yes, as its not specified=C2= =A0as a domain or domain-like, it would be odd to specify a domain encoding= .

Brandon

On Mon, Mar 30, 2020 at 2:08 PM Damian Lukows= ki <rfc@arcsin.de> wrote:
> Hmm, we didn'= t include this in RFC 8616 either, I could imagine that it
> should be punycoded=C2=A0also, though=C2=A0it really depends on whethe= r in 6532 or
> 5322.
Why punycoded? Section 2.5 does not specify that it needs to be a domain name, even though it usually is.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000003cab2905a218ee4e-- From nobody Mon Mar 30 14:23:17 2020 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 363B03A1357 for ; Mon, 30 Mar 2020 14:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WKMI/EYj; dkim=pass (1536-bit key) header.d=taugh.com header.b=CNCiAm17 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 RChoKY1cT2hj for ; Mon, 30 Mar 2020 14:23:14 -0700 (PDT) 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 AB9CB3A082A for ; Mon, 30 Mar 2020 14:23:14 -0700 (PDT) Received: (qmail 35678 invoked from network); 30 Mar 2020 21:23:12 -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=8b59.5e826340.k2003; bh=E6iRHIPEkIdvfznzRueWxLH3CnkqhWrkAW22NYi7lwg=; b=WKMI/EYjc5/vsYpHcQ/3XDWa+52IRddy7HUd7U3jcSWRitvSbLja1c6UcJ2kW9d4FJcbt6xl9l0FrmzQrC+o9O5DyzXHWIvgmOxeTj5yISFshJ3jhdVcZudcSFfV4ts8P/DvVZXettpamtB3lVHn71x/3nTviP8V9bOFHLSLUWKBjhL1aZW44OWLBUkIdS1Iu1Uv0zyOqq/cAtcF9wCHtgXf7qMF2kNC6JnPrB+ZQErvRmjoAIQZzCa1Z106AiAQ 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=8b59.5e826340.k2003; bh=E6iRHIPEkIdvfznzRueWxLH3CnkqhWrkAW22NYi7lwg=; b=CNCiAm177l5ZgVgPUR0xt8yerXfSPL2LvHrAp9PiBq3mVREODHADCyBv8IA0dbkbwudsh+I2bhXfMEq+dv60nYEP8U+bjM8f0vWD12Oc64Zl+ezEvnek0fOTkq7u/ciiLohvV0q5mJiMj4wb5cWwFiBtKg4YDzl3tCvG7fqvEhvm8dQ3TbtflUcBfEOUTz9aIcHz3kffp3S4zZyOq0nBbRoCzHMtntKJ6CpaWfY9AZCKx/1Itp/qwE4wr6kDKMS3 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 ESMTP via TCP6; 30 Mar 2020 21:23:12 -0000 Received: by ary.qy (Postfix, from userid 501) id 341EB16CFEA5; Mon, 30 Mar 2020 17:23:11 -0400 (EDT) Date: 30 Mar 2020 17:23:11 -0400 Message-Id: <20200330212312.341EB16CFEA5@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: blong@google.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] Definition of "value" in RFC8601 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, 30 Mar 2020 21:23:16 -0000 In article you write: >-=-=-=-=-=- > >Hmm, we didn't include this in RFC 8616 either, I could imagine that it >should be punycoded also, though it really depends on whether in 6532 or >5322. This is another mistake in the ABNF in 8601. The point of 6532 is that with the exception of Message-IDs, any header fields that used to be limited to ASCII can now contain UTF-8 printable characters. If you're putting an A-R header on an EAI message, it has to allow UTF-8 since lots of the fields in an A-R header can contain mailboxes and other UTF-8 strings. I realize that the authserv-id is usually a domain name, in which case it would be reasonable to represent it as A-labels, but it doesn't have to be. The only, and I mean ONLY, strings that are "punycoded" are the characters in IDN labels that follow xn--. To pick a common point of confusion, you absolutely cannot "punycode" a mailbox name. R's, John >On Sat, Mar 28, 2020 at 3:39 AM Damian Lukowski wrote: > >> Hello, >> >> RFC8601 section 2.2 defines >> >> > authserv-id = value >> > ; see below for a description of this element >> > [...] >> > The "value" is as defined in Section 5.1 of [MIME], with >> > "quoted-string" updated as specified in [RFC6532]. >> [MIME] (RFC2045) section 5.1 >> >> > value := token / quoted-string >> > token := 1*> > or tspecials> >> >> The token is not said to be updated by [RFC6532] as is quoted-string, so >> by my interpretation non-ASCII cannot be used without quotes. >> >> If so, then current implementations of OpenDKIM and OpenDMARC are wrong >> or imcomplete, as they do not check for Non-ASCII AuthservID and produce >> headers like >> >> > Authentication-Results: öde; dkim=none; dkim-atps=neutral >> Is my understanding correct? From nobody Mon Mar 30 15:39:06 2020 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 068163A14BA for ; Mon, 30 Mar 2020 15:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MkNnpq1Sq62e for ; Mon, 30 Mar 2020 15:39:03 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 C254A3A14B9 for ; Mon, 30 Mar 2020 15:39:03 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id b187so5172005vkh.12 for ; Mon, 30 Mar 2020 15:39:03 -0700 (PDT) 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=GwXtVeXUzKRKr7ojBXXQkcVwvbiHmBcTNRMuooZfY+I=; b=JpZXgAidLe4sp9WbCGutalITrn7zTrgJXQuot3+F3gxrrtePqz7QjL2gtMO3U8cjxZ 6OWuGXU1/1AsBkqLxyfZx3nBJMeOfQ8jZqRVucgl3xNza58AEfHppzTGYuBl0SwAtWl8 qn8rF9NOLQ26FfVPm89f5LoDD4zju5epk5VFpnmTDTY4VnGSRPRGjSdpjVIAob7/qhwO BP5jIZKy1efUhmhoxPn2n9RhBRKLhBe11x3XOzIDnNyEq5zCNYcNhuAl02lPG3R1LlES a5drIt/hyObkKCKKJWMCDKH0FHmm1huqrytSX2F6JeUSsYQvgeaqAg+x786Yq9y6SRld 4LGA== 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=GwXtVeXUzKRKr7ojBXXQkcVwvbiHmBcTNRMuooZfY+I=; b=Qgl+9srcm57kf4f163dxUbQj2fyx1o3S8FfC8Gxa9C3kH2zhc8FeYBjk17E57+ih33 o4d2j8UAZa6FNR0VnkR+P/o8HMGCp8ZVowJrO3OzGlcsYDvCuWKPrGV9uozDVJADyA7z vSfrBM9HWmeT3caSKNw7WaWzKIYbN3Dnj42XzC2qz3RxZq/BHYrbPeO4UoTJNOs87OzV L1Y0isHjV2h5NJ6bxo7DuaatrWTJGjgEiLAnjxeU6ZhAtvw6N3hdfih30OsH+XMOC51E grctX04y466SAWovPvew2VnMt2moQRDEjjborxLTyH4HoxkGeHXFytH+RhzKUTqMQptv dfbg== X-Gm-Message-State: AGi0Pubua/rGzRLjARrXRgGtmBDL5sZI55SVCArgNplv4o6R5CMEc8+Q CBWwErOo3l0w3AEevuJjV9ahqLBcQMKADzz3lMs= X-Google-Smtp-Source: APiQypLTTs1x8hLtUdAhd67U5NigEOREkLtEe3x4ZcKZDNlqm5pGHblOOafIFpMAMavPPDoKbDv0iOpwcgg9z6rYcYc= X-Received: by 2002:ac5:cdc7:: with SMTP id u7mr10222981vkn.8.1585607942773; Mon, 30 Mar 2020 15:39:02 -0700 (PDT) MIME-Version: 1.0 References: <20200330212312.341EB16CFEA5@ary.qy> In-Reply-To: <20200330212312.341EB16CFEA5@ary.qy> From: "Murray S. Kucherawy" Date: Mon, 30 Mar 2020 15:38:51 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , Brandon Long Content-Type: multipart/alternative; boundary="0000000000002ea0d505a21a1ec4" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 30 Mar 2020 22:39:05 -0000 --0000000000002ea0d505a21a1ec4 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 30, 2020 at 2:23 PM John Levine wrote: > In article < > CABa8R6tTPAtEyPRSGbWKafZVZ4u8v8sN1VpTpMLQCia2_+5zRg@mail.gmail.com> you > write: > >-=-=-=-=-=- > > > >Hmm, we didn't include this in RFC 8616 either, I could imagine that it > >should be punycoded also, though it really depends on whether in 6532 or > >5322. > > This is another mistake in the ABNF in 8601. The point of 6532 is > that with the exception of Message-IDs, any header fields that used to > be limited to ASCII can now contain UTF-8 printable characters. > Does someone have a fix in mind that could be submitted as an erratum? The intent was indeed to make the authserv-id either a plain old ASCII domain name or an A-label which doesn't need quoting. I missed that RFC 6532 didn't update "value", unfortunately. -MSK --0000000000002ea0d505a21a1ec4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 30, 2020 at 2:23 PM John Levi= ne <johnl@taugh.com> wrote:
In article <CABa8R6tTPAtEyPRSG= bWKafZVZ4u8v8sN1VpTpMLQCia2_+5zRg@mail.gmail.com> you write:
>-=3D-=3D-=3D-=3D-=3D-
>
>Hmm, we didn't include this in RFC 8616 either, I could imagine tha= t it
>should be punycoded also, though it really depends on whether in 6532 o= r
>5322.

This is another mistake in the ABNF in 8601.=C2=A0 The point of 6532 is
that with the exception of Message-IDs, any header fields that used to
be limited to ASCII can now contain UTF-8 printable characters.

= Does someone have a fix in mind that could be submitted as an erratum?=C2= =A0 The intent was indeed to make the authserv-id either a plain old ASCII = domain name or an A-label which doesn't need quoting.=C2=A0 I missed th= at RFC 6532 didn't update "value", unfortunately.

-MSK
--0000000000002ea0d505a21a1ec4-- From nobody Mon Mar 30 16:21:25 2020 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 F37203A1579 for ; Mon, 30 Mar 2020 16:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NQwW1a8M; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZjwVgDku 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 IjKNs1R3k2JG for ; Mon, 30 Mar 2020 16:21:22 -0700 (PDT) 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 22B453A1577 for ; Mon, 30 Mar 2020 16:21:21 -0700 (PDT) Received: (qmail 65210 invoked from network); 30 Mar 2020 23:21:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=feb8.5e827eef.k2003; i=johnl-iecc.com@submit.iecc.com; bh=o6cbwgoym2sZYdCJYrNKO+ax1IHZYUUgD3GGjgJl4lM=; b=NQwW1a8MHl7ySCxSCnzUDc2ZiOGoA3htdJsLuHeJ8xBetIBLsEELFhzTvKl/CbOyZPVhI3r2DASGkiDdhgMYWu7pHg23UkPathAF6dLf+dEjOQEhw0hb0AERvrp48BNsZLBTIQd6CxdOGpYViTfV3nB6lkMLkEQLKbfvt4FJQjsdPGbeLSbYUEnZFHT9aAWCMPMdZsXddEeOBmU8QIJoD8OgZSkg7NJwQTRGLFbao2wTarD3QuExRWJX21qpy88n DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=feb8.5e827eef.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=o6cbwgoym2sZYdCJYrNKO+ax1IHZYUUgD3GGjgJl4lM=; b=ZjwVgDkuUjm5C6lgAlkpx1ZKq7FvdfoHblNShje2G+F/1KYQS2F4TXlt1XbeLAhcmpFbLmvfZmDv5+wP1z6BhoYRjEK1BNxcG7Mwpz0Pd+WbrfLKIiLzF967Tfl8YFgJcXyBf/Qd7dYdr4hXm+Ew3b2UiknN1HRijppvA4q2uhdC5AAvEOI6DZk8/2NrQscmGrpkR3gRwb1UOMue9kvvRK6F22Lg4CD+leBcpbKjUUckXsfD2CITqasUfAP29op9 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 30 Mar 2020 23:21:18 -0000 Date: 30 Mar 2020 19:21:18 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <20200330212312.341EB16CFEA5@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 30 Mar 2020 23:21:24 -0000 > Does someone have a fix in mind that could be submitted as an erratum? The > intent was indeed to make the authserv-id either a plain old ASCII domain > name or an A-label which doesn't need quoting. I missed that RFC 6532 > didn't update "value", unfortunately. Unfortunately, 8601's defintion is a mess. At the bottom of page 15 it says this about authserv-id, which contradicts the ABNF: Note that in an EAI-formatted message, this identifier may be expressed in UTF-8. If you want it to be a domain, the ABNF should say: authserv-id = domain-name The text below says domain-name is imported from RFC 6376, which I presume includes the updates from RFC 8616 that encourage U-labels in EAI messages. This is not strictly backward compatible with the current text, but I don't think I've ever seen an authserv-id which wasn't syntactically a domain name. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Mar 30 22:43:50 2020 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 A423F3A1B9B for ; Mon, 30 Mar 2020 22:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6XP1H8drzB_u for ; Mon, 30 Mar 2020 22:43:47 -0700 (PDT) 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 156893A1B99 for ; Mon, 30 Mar 2020 22:43:47 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id y17so7218312uap.13 for ; Mon, 30 Mar 2020 22:43:47 -0700 (PDT) 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=WxaKFCvtTLNz3LUBG8v1Mw032Ju8M2YRzWlBQBQs9fA=; b=Etop1M//T6V1S/Qo7q6FQd+OZPxmBj2Fj8y6jFN+m4dcsJJOJZuAyNC4uQZBCReA/d WDdsvIH0IYQAkOcYfgbTfSXM6HbNs35kz+s1cRMp5tsiAirozxPlMVwYKGUwGHk8cq5x yo8uXmPc9gokuVZ7JG6rxgFEa0HfIHH7AeoqpU2agaMXZNk3V2v/apzdPXlLDM8AjfRk i4fCu3lI+NiD88qC0MI9DgN+/0P6pnTpRQIavpx/6JzEweIMzJWmUj3uztO6SC+Crojc O83XSUpM694kTI9RUNDmR/K81XPkxOrAnL9XudTnB7lIw7+sjF1ZutUnRZBffsmQLl6Z yeAQ== 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=WxaKFCvtTLNz3LUBG8v1Mw032Ju8M2YRzWlBQBQs9fA=; b=aA3k+oGmRoHsK8j6EEyLzalPr/vGfXN0w9Hjm1RV/LwpfWaVlmiB8AS5bKZUa65Fro YesMLLK8oYjGZ4/huEjCAGt0GmIStmrAepORqIlZUvNc0Sj8qfl2GLxOwe/Z3sJ6xpM6 kgwLtqdIRDSpGk0t3V2l5NQXjCvt1VhLzsifesv2MYTA3biMMiw/ij960KBam15q/DBr KjIfmi6JVck7zmJUqjSdacWEv5XwyOE9IvegB1jvqvXzw/fQMlygOPP9mQhkgtee1K2W U30Sb/mtM9t+lhZ+7SRVOlDYQKT49Z3FpsigQjB6biAsljNO2w99jbErjvEyTzXvjZqN b2wQ== X-Gm-Message-State: AGi0PuYspTprzoV7sQvILyXGIab1ptJH5SIHjefpy0zBjh5jDnkI49FL bimenARaK2mdsKC6lKktn81zd+/zIfiKx61OAEBq4SGF X-Google-Smtp-Source: APiQypIu98qpWyAN3lAkqhosXLkFgehWI1BVgNZnCasdQN2DkiaKcDaTxmra2lDyx6+TAGVm0ekyRTchuBBDtGCRNCY= X-Received: by 2002:a9f:2204:: with SMTP id 4mr10223089uad.87.1585633425977; Mon, 30 Mar 2020 22:43:45 -0700 (PDT) MIME-Version: 1.0 References: <20200330212312.341EB16CFEA5@ary.qy> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 30 Mar 2020 22:43:34 -0700 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001976eb05a2200d48" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 05:43:49 -0000 --0000000000001976eb05a2200d48 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 30, 2020 at 4:21 PM John R Levine wrote: > > Does someone have a fix in mind that could be submitted as an erratum? > The > > intent was indeed to make the authserv-id either a plain old ASCII domain > > name or an A-label which doesn't need quoting. I missed that RFC 6532 > > didn't update "value", unfortunately. > > Unfortunately, 8601's defintion is a mess. At the bottom of page 15 it > says this about authserv-id, which contradicts the ABNF: > [...] > OK, what does the WG think might be the best way to clean it up? -MSK --0000000000001976eb05a2200d48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 30, 2020 at 4:21 PM John R Le= vine <johnl@taugh.com> wrote:<= br>
> Does someone have a fix in mind that could be submitted as = an erratum?=C2=A0 The
> intent was indeed to make the authserv-id either a plain old ASCII dom= ain
> name or an A-label which doesn't need quoting.=C2=A0 I missed that= RFC 6532
> didn't update "value", unfortunately.

Unfortunately, 8601's defintion is a mess.=C2=A0 At the bottom of page = 15 it
says this about authserv-id, which contradicts the ABNF:
[...]

OK, what does the WG think might be the best wa= y to clean it up?

-MSK
--0000000000001976eb05a2200d48-- From nobody Mon Mar 30 23:22:35 2020 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 703B03A1C17 for ; Mon, 30 Mar 2020 23:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 cFwnyCdkI6og for ; Mon, 30 Mar 2020 23:22:32 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46433A1BFD for ; Mon, 30 Mar 2020 23:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585635746; x=1587450147; bh=UZl6X2/1Pztyzl7x3j/5AWGbWo/K4Gol6Sg WA6YXxEo=; b=gNjJxALZOSC0QUih6NC5Z3fOghO72GHi+8busgLk2WXRi4d77cg bwxKY/ozfOhzDlfwEfYr7LA8La4MWn5ZtS3wdPt3141e7HGcxVaA02+m+ClWo6dT GES3SXqRJSfHuvBORMKy+0NscAKoHR5zvWo+es+bFT+rtwjOq3RwmMRA= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200330212312.341EB16CFEA5@ary.qy> From: Damian Lukowski Message-ID: <230d0260-c254-99d3-0995-1ab05c326949@arcsin.de> Date: Tue, 31 Mar 2020 08:23:04 +0200 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] Definition of "value" in RFC8601 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, 31 Mar 2020 06:22:34 -0000 > The intent was indeed to make the authserv-id either a plain old ASCII > domain name or an A-label which doesn't need quoting.  I missed that RFC > 6532 didn't update "value", unfortunately. I don't understand. If the intent is to have an old ASCII domain, or A-labels (still ASCII), then why is it relevant that "value" has not been updated to include real UTF-8? Shall authserv-id contain UTF8-non-ascii or not? Damian From nobody Tue Mar 31 08:55:19 2020 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 2C6193A235F for ; Tue, 31 Mar 2020 08:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=OXvuLFsy; dkim=pass (2048-bit key) header.d=kitterman.com header.b=HDw8dbJb 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 RDphXIlNY3dj for ; Tue, 31 Mar 2020 08:55:15 -0700 (PDT) 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 5E45C3A235C for ; Tue, 31 Mar 2020 08:55:15 -0700 (PDT) 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 B9277F802AF for ; Tue, 31 Mar 2020 11:55:13 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1585670113; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=o3GSjBWMdCQODv5PF7NOhdbNi54eBjqnH+Zk6oAbjDU=; b=OXvuLFsy7F1aOhsBH+id3PTp+FI4kvXMTaGv8zr9ioRxdt5Evmp65GzhpBlfVAotX3Hv8 Fxg1FjJqLkG6VvVAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1585670113; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=o3GSjBWMdCQODv5PF7NOhdbNi54eBjqnH+Zk6oAbjDU=; b=HDw8dbJbr6WgDbYYENT94JcbShH/sFDPNC//3Q3Ml0ucIks/CG3g5uW2SQBiVWu3b22x0 e0iXuGIOVAJXy6vtqlwF2YrNXK44tO+yyKPqrQGN1KIjBaCksKx7uKV6oc+FM7I11DnPH9B 9ibOmKP1YDuxRWLpIWu+3ZJFLO/NB++jeorxtk46WOi58rDgphNgzSTAf+MYYg87ElJN93h cUl9S3YfksaoaQEUqnPO94XHDH2V89L9yZVARDMUZsGuuxk13WBNd0FntxTyiKG/E9rGePs a0QQytsGnHjJ7+qkDifkBTd6IaLJK5H8sNzSNPKKXfgZxhFgW7kkuX41vCOQ== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8F844F80157 for ; Tue, 31 Mar 2020 11:55:13 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 31 Mar 2020 11:55:02 -0400 Message-ID: <3295240.vh5t8hYAJM@sk-desktop> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 15:55:17 -0000 On Monday, March 30, 2020 7:21:18 PM EDT John R Levine wrote: > > Does someone have a fix in mind that could be submitted as an erratum? > > The > > intent was indeed to make the authserv-id either a plain old ASCII domain > > name or an A-label which doesn't need quoting. I missed that RFC 6532 > > didn't update "value", unfortunately. > > Unfortunately, 8601's defintion is a mess. At the bottom of page 15 it > says this about authserv-id, which contradicts the ABNF: > > Note that in an EAI-formatted message, this identifier may be > expressed in UTF-8. > > If you want it to be a domain, the ABNF should say: > > authserv-id = domain-name > > The text below says domain-name is imported from RFC 6376, which I presume > includes the updates from RFC 8616 that encourage U-labels in EAI > messages. > > This is not strictly backward compatible with the current text, but I > don't think I've ever seen an authserv-id which wasn't syntactically a > domain name. I've seen bare host names used. I guess that's syntactically a domain name also, but might not be what you expect if you assume it's really a domain name. It probably doesn't matter. Scott K From nobody Tue Mar 31 08:55:57 2020 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 AF1993A235F for ; Tue, 31 Mar 2020 08:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 k-amK5RQD0cP for ; Tue, 31 Mar 2020 08:55:53 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 0A1353A235C for ; Tue, 31 Mar 2020 08:55:52 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id x9so15781405iom.10 for ; Tue, 31 Mar 2020 08:55:52 -0700 (PDT) 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=yEk38+qqtKMYFezGzjtu+p9tZxM/mfBA5tFQV5cUvIQ=; b=KhZfPlGnIsT01b8a43EGfPaYmtcpDs5Pmc+JZEffkRhf/ROKq2h7YL+1GnC9hlMUG/ 4klHVlchh6I0RWrU9TZPcbYaG1kbGIdz/M4UeBDAkZyPYuFJIFOb1zWZQGofJnfexOuG kNqr0/zxg5lufvstoRg2ELmwRu0+ag/YCkD/M= 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=yEk38+qqtKMYFezGzjtu+p9tZxM/mfBA5tFQV5cUvIQ=; b=lRTNyrZ3Yl5vh+hq3hOJgPARuQ4+O2K1YhVLMMCCIQ+a2/En2H3/UJtH5k0wEyobPf /HA+VNcMXxEhmyF9Cz5hhkWyO9SgSafTynfJ4LGdJEHap4bV8T94c/kiHfIhUt3GtuK5 4+N0oc1mNH08cbT2MXO1tLMpAasTNAZywNDW/Alp2aMaN04QxRE/MQB9WtQEJY/GgvVU TBc324ULTOYa3ybUUrLKNY/xnrHuTm87EaWlPaVKwMZiZmhyEAKndNoCTxOZ49RaSq3k R/4o1zw5GqOHejUMS0SnMecKYYTLkzQ6y9l0XLuFo+ARdPTuk9oGkJ0NbRCOkDegudbd 6tyg== X-Gm-Message-State: ANhLgQ1xLSqClsXdKhNWVQ6CrSpL880pMBJOhC8E6m6unrxu6QmvyvCQ Ap+4mHnCmriAZp4ool2PdPHBX3dDQxBtHvNJ63BWfQ== X-Google-Smtp-Source: ADFU+vsLAzb5WC3fRH7Q64dU91AwW8fakzcC1kg/h2GtSPaKc23cPp4OIWdw33v4MLh1XIzGoI6qQRq+tO80g2Kfs58= X-Received: by 2002:a6b:d808:: with SMTP id y8mr1825916iob.121.1585670151914; Tue, 31 Mar 2020 08:55:51 -0700 (PDT) MIME-Version: 1.0 References: <20200330212312.341EB16CFEA5@ary.qy> In-Reply-To: From: "Kurt Andersen (b)" Date: Tue, 31 Mar 2020 08:55:32 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: John R Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000022dbad05a2289a8c" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 15:55:56 -0000 --00000000000022dbad05a2289a8c Content-Type: text/plain; charset="UTF-8" On Mon, Mar 30, 2020 at 10:43 PM Murray S. Kucherawy wrote: > On Mon, Mar 30, 2020 at 4:21 PM John R Levine wrote: > >> > Does someone have a fix in mind that could be submitted as an erratum? >> The >> > intent was indeed to make the authserv-id either a plain old ASCII >> domain >> > name or an A-label which doesn't need quoting. I missed that RFC 6532 >> > didn't update "value", unfortunately. >> >> Unfortunately, 8601's defintion is a mess. At the bottom of page 15 it >> says this about authserv-id, which contradicts the ABNF: >> [...] >> > > OK, what does the WG think might be the best way to clean it up? > I think that John's suggestion (ABNF: " authserv-id = domain-name ") makes the most sense and the fewest contortions. --Kurt --00000000000022dbad05a2289a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 30, 2020 at 10:43 PM Murray S= . Kucherawy <superuser@gmail.com<= /a>> wrote:
> Does someone ha= ve a fix in mind that could be submitted as an erratum?=C2=A0 The
> intent was indeed to make the authserv-id either a plain old ASCII dom= ain
> name or an A-label which doesn't need quoting.=C2=A0 I missed that= RFC 6532
> didn't update "value", unfortunately.

Unfortunately, 8601's defintion is a mess.=C2=A0 At the bottom of page = 15 it
says this about authserv-id, which contradicts the ABNF:
[...]

OK, what does the WG think might be the best wa= y to clean it up?

=C2=A0I= think that John's suggestion (ABNF: " authserv-id =3D domain-name= ") makes the most sense and the fewest contortions.

--Kurt
--00000000000022dbad05a2289a8c-- From nobody Tue Mar 31 09:28:47 2020 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 61BD03A17E5 for ; Tue, 31 Mar 2020 09:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 viD1x4tK3jKi for ; Tue, 31 Mar 2020 09:28:43 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 909333A17E1 for ; Tue, 31 Mar 2020 09:28:43 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id l23so22658845otf.3 for ; Tue, 31 Mar 2020 09:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g6lHEfzrWt2XevkuDQYMoz7zOm2U0uxig2NOvgVy3Os=; b=fXj05m4XJm5C8uiwKL5YRivhDHpLPY8nGctXnoR5E2vt667Qgvv/Z4wtWuP5pusXkH oJXDJq41NtNx8v4uIobG1rI1N1PDceuuzpupJdOTmih/R738rR8x0tasQsbpdFTVDZd+ nTLfcUhRvz6FurGmxiOvOnpT6dk0+N+5L+/YqPrbxpdCIzKQAu3vOxBUjI2RM4+zvZRR 9nOWs3u6EhqE+exUriG7P5C7kGeJEmqf6t6zXWERKc8c26mICTgv9DelmJ3nH+68mQx7 WIzIs3JFam/65KG9bQLGmcJDqEHkAjoRduwL7I6KgG20c56xwRy7QawWAI6D7sdsB0NR s9nQ== 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=g6lHEfzrWt2XevkuDQYMoz7zOm2U0uxig2NOvgVy3Os=; b=H3sjYEdzUxcZoL6k4yBwRBpAGC4jr/bIuszMjDgxrkASExSrHFtRTfJsrH1itJMa8b CDuYRT2ESE/Gqd/tBgxbAXmFWUjCTlIfhmnRMUKZ1VBDdLYX/ACC2T5uTmTmBW/QA4uw 8A5aEL+WH8XAZc3p+Jw+RZeOM9EWYl64ntdErbbRtKxxhToAcJWHDkuaR9n06ddpbXzc yuXok5d8dd+ian90hNyrkNHNWxDxUKpAI9BZcn9pv8NskLADgBNvNuJCmsRhqOUn9AIF 90jdJcvuyUDsqfrTm0w31BlfbfTgoLWNoc/g7+YO2Iu/eNGgEOHNNrDrVw3PmPxo7OUW 0iNQ== X-Gm-Message-State: ANhLgQ0wCGISii1o+J0HqZEzGJVlms5qJpz7CCs5FaGACJXNUrBEfomu q03NQlH3UEXkyw49ifGbEkKjDZBxETVdtBKuikgkbA== X-Google-Smtp-Source: ADFU+vsazJ3aQoCNygV5ILZ92t+UlICldJkOXljVMC9wQ1/Dm4ATTxISm33cCZ1zs93hHJqNDSEdzHev3gSscWlboSA= X-Received: by 2002:a9d:6c94:: with SMTP id c20mr1389487otr.49.1585672122415; Tue, 31 Mar 2020 09:28:42 -0700 (PDT) MIME-Version: 1.0 References: <20200330212312.341EB16CFEA5@ary.qy> In-Reply-To: From: Seth Blank Date: Tue, 31 Mar 2020 09:28:26 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , IETF DMARC WG , John R Levine Content-Type: multipart/alternative; boundary="00000000000096583f05a2290ff6" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 16:28:45 -0000 --00000000000096583f05a2290ff6 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 31, 2020 at 8:56 AM Kurt Andersen (b) wrote: > I think that John's suggestion (ABNF: " authserv-id = domain-name ") > makes the most sense and the fewest contortions. > (as an individual) I've definitely seen non domain-name based authserv-ids, but they are rare and tend to be from opendmarc. We can certainly fix that in opendmarc. I do think John's suggestion is the most straightforward, and I'm for it, but it does constitute a breaking change. Seth --00000000000096583f05a2290ff6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 31, 2020 at 8:56 AM Kurt Ande= rsen (b) <kboth@drkurt.com> w= rote:
=C2=A0I think that John&= #39;s suggestion (ABNF: " authserv-id =3D domain-name ") makes th= e most sense and the fewest contortions.

<= /div>
(as an individual)

I've definitely s= een non domain-name based authserv-ids, but they are rare and tend to be fr= om opendmarc. We can certainly fix that in opendmarc.

<= div>I do think John's suggestion is the most straightforward, and I'= ;m for it, but it does constitute=C2=A0a breaking change.

Seth
--00000000000096583f05a2290ff6-- From nobody Tue Mar 31 09:57:00 2020 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 7523E3A244D for ; Tue, 31 Mar 2020 09:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=gYRufM4S; dkim=pass (1536-bit key) header.d=taugh.com header.b=JduCKyQC 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 QQo8sf0NUySc for ; Tue, 31 Mar 2020 09:56:56 -0700 (PDT) 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 D44AE3A244B for ; Tue, 31 Mar 2020 09:56:55 -0700 (PDT) Received: (qmail 20837 invoked from network); 31 Mar 2020 16:56:53 -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=5163.5e837655.k2003; bh=ZGTkiyC6tgEhisCNfxs8jnwwlWVQikqrSiVdMfZ5dEg=; b=gYRufM4SmFg2MF33fFk/nHooBFz2YEZPF5di5xFofBrjg6NqicAp+nDQyTV5sqLldpZ5hKDslBFYx9an39hBM6Hfs0UBEIKewi55MiSIPwnzr/nM4r85kv4zIzI9r26jWntVj7W4rgRcirBwVW1KbWXUb5KYW+xuA2Ad5mDeeOGA8dNramcwhSkky4Oea0yOO5HmTK44YtJ9wNg104l6CTNEm6WqkSy0aq8h+5VsZZErbUS38JDs3xDZQHbiwUrK 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=5163.5e837655.k2003; bh=ZGTkiyC6tgEhisCNfxs8jnwwlWVQikqrSiVdMfZ5dEg=; b=JduCKyQCXCmmDefsrZbYxnUfUDZw9Z9sqASEfvnDDpgd9wkFJTtTS1zVyL95pB2BJzLY1rEtIWz+lTszInGgz22OSxYy8IP3sTmnLyPM/L3pLVpN8CbUzVjlrHsnDuYex0EhdQbncJ6ux/6NVt12LRmqLe+SvsZp9/XH6y5vnhcxC7FvMBXSYfAJZoudPHpFH0lKX4ymCLLFCmchHL1N8T5cedVYaqcoDny0z2rgpjh//EJX3gADU2DDHmiLvazi 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 ESMTP via TCP6; 31 Mar 2020 16:56:52 -0000 Received: by ary.qy (Postfix, from userid 501) id 84C5916D54B5; Tue, 31 Mar 2020 12:56:51 -0400 (EDT) Date: 31 Mar 2020 12:56:51 -0400 Message-Id: <20200331165652.84C5916D54B5@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <3295240.vh5t8hYAJM@sk-desktop> 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] Definition of "value" in RFC8601 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, 31 Mar 2020 16:56:59 -0000 In article <3295240.vh5t8hYAJM@sk-desktop> you write: >> If you want it to be a domain, the ABNF should say: >> >> authserv-id = domain-name >> This is not strictly backward compatible with the current text, but I >> don't think I've ever seen an authserv-id which wasn't syntactically a >> domain name. > >I've seen bare host names used. I guess that's syntactically a domain name >also, but might not be what you expect if you assume it's really a domain >name. It probably doesn't matter. I don't see any reason to exclude them. We could do this: autbserv-id = sub-domain *("." sub-domain) Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI mail. R's, John From nobody Tue Mar 31 09:58:15 2020 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 D71B23A1924 for ; Tue, 31 Mar 2020 09:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=g5RwDp0k; dkim=pass (1536-bit key) header.d=taugh.com header.b=f7igPjwD 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 OUAXnSZDpHS4 for ; Tue, 31 Mar 2020 09:58:11 -0700 (PDT) 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 A9BE43A1893 for ; Tue, 31 Mar 2020 09:58:11 -0700 (PDT) Received: (qmail 21288 invoked from network); 31 Mar 2020 16:58: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=531d.5e8376a2.k2003; bh=w+B5keE4pzIDdfSXbf7ImfSrC6NAbAEPS5cKE0iQNWw=; b=g5RwDp0kNWgb2XtqIHJrRRQZPl9WzRWKvcbsYOU8PxeSIKg+2Yym0pp1HA0+SixEtimRaeVqXuHNLq6MpFtWfohnPNcPrmced7a3+LZWoydCfRYZq7i97h6oWkQDCyGjOHbeM0+FJ/om6Ep4S2Vq2F/PMGyLgUdauCPIOPQSzIcVkRb3ofmOzgFMPMDPiFJPjG9HKdqSUNWBrUIBPSWH/P9DTyKXs4N2RKA7WCp4VybzTPJR7+WKK/z3KHpZcu9d 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=531d.5e8376a2.k2003; bh=w+B5keE4pzIDdfSXbf7ImfSrC6NAbAEPS5cKE0iQNWw=; b=f7igPjwDZtIwLIjskBhZFKISTi3h/uH/WYaOPw9962GrbK/XsP7E8fGkeD6aX2ZLwo9xLT/J6nNRvkFQiWlsr0vSNYvKnfY1BV7SQWm6Luc/pdwwm6z2pHsyAfUpI6SbHSzaeJAva8xQxGvwu7fxUC7UViRYH8xM+co3t2kH3sTH6A0YkIKeUPw32LqTsFpk0jcQx2pzsex57qwd4Kv7Mf/aqdMYsrrYD6OStnRsMC2o6GUfUWsKf8YQn1UiEeOa 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 ESMTP via TCP6; 31 Mar 2020 16:58:10 -0000 Received: by ary.qy (Postfix, from userid 501) id 6148016D54F4; Tue, 31 Mar 2020 12:58:10 -0400 (EDT) Date: 31 Mar 2020 12:58:10 -0400 Message-Id: <20200331165810.6148016D54F4@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de In-Reply-To: <230d0260-c254-99d3-0995-1ab05c326949@arcsin.de> 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] Definition of "value" in RFC8601 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, 31 Mar 2020 16:58:14 -0000 In article <230d0260-c254-99d3-0995-1ab05c326949@arcsin.de> you write: >Shall authserv-id contain UTF8-non-ascii or not? The intention in 8601 is pretty clear, even though the ABNF doesn't agree: 2.5. Authentication Service Identifier Field Every Authentication-Results header field has an authentication service identifier field (authserv-id above). Specifically, this is any string intended to identify the authentication service within the ADMD that conducted authentication checks on the message. This identifier is intended to be machine-readable and not necessarily meaningful to users. Note that in an EAI-formatted message, this identifier may be expressed in UTF-8. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Mar 31 10:00:46 2020 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 3DAA93A2459 for ; Tue, 31 Mar 2020 10:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=vno5qRAZ; dkim=pass (1536-bit key) header.d=taugh.com header.b=PH7hhDeB 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 Q82ijMjMAGLJ for ; Tue, 31 Mar 2020 10:00:42 -0700 (PDT) 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 B1BAE3A2456 for ; Tue, 31 Mar 2020 10:00:42 -0700 (PDT) Received: (qmail 22372 invoked from network); 31 Mar 2020 17:00:41 -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=575f.5e837739.k2003; bh=Po6OdhkSlZ9uFtIUDbUX/Sq7gA5mxNdC0YvmKmGu1wc=; b=vno5qRAZ9HtkJu0cegvVGll3Afe1B8uBaAy4R71411gufjjpQ1SdZzy7ChjMX4w347CaiiKAbayQVaoaunhzbHZKiJ1Jz62ATCEko+e3/FyAxJ8svNeCejoOANXppFwu0ZCQXZvHiDRaeARs+eAFhreFyCyYD3/PEH2GHDlgZhwzzQhzWdAdUf+wfC4j9GBj2vtrZ5GpNRBQ7vQsi4OQ7jra/WJlsWpEx4ciB3QQUUVoT4G/xkBE1E7WDDW4unjd 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=575f.5e837739.k2003; bh=Po6OdhkSlZ9uFtIUDbUX/Sq7gA5mxNdC0YvmKmGu1wc=; b=PH7hhDeBIMVi3aIUFST9ihTALS9JcHJuEV7BG3q3Bjwd00tRyh8EdRPebEDQK1KWAA5jlqbUcLl0OaKYvi6zf6EzN9bSajoOlLqssI7tIBr7hCRFmB5fh9vv4wvlPoQK8smxKBsz1lGQZn9suxOh15Ss83hbQLz5MhUDo2yt6HCO9Ki3WKa9R66krfcM+PTVfYaOPMdQdMU4FfguNg+sUN5/slt/VzDvz727PdxTPXLR8f/kopKhMMvt98915g9g 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 ESMTP via TCP6; 31 Mar 2020 17:00:41 -0000 Received: by ary.qy (Postfix, from userid 501) id 31C6816D554A; Tue, 31 Mar 2020 13:00:40 -0400 (EDT) Date: 31 Mar 2020 13:00:40 -0400 Message-Id: <20200331170041.31C6816D554A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@sethblank.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] Definition of "value" in RFC8601 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, 31 Mar 2020 17:00:44 -0000 In article you write: >I've definitely seen non domain-name based authserv-ids, but they are rare >and tend to be from opendmarc. We can certainly fix that in opendmarc. My proposal says they're syntactically domain names, not that they actually have to exist in the DNS. What do those ID's look like? The only things I can think of likely to fail would be exotica like foo..bar that can't be parsed into DNS labels. From nobody Tue Mar 31 10:08:05 2020 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 C13C13A24F5 for ; Tue, 31 Mar 2020 10:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=nVIq+eBo; dkim=pass (2048-bit key) header.d=kitterman.com header.b=a5ydcKKd 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 YNFhwTzHZfPM for ; Tue, 31 Mar 2020 10:07:56 -0700 (PDT) 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 38E1C3A250A for ; Tue, 31 Mar 2020 10:07:42 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 43FABF80120; Tue, 31 Mar 2020 13:07:41 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1585674461; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=XQme6pU20IGvq/AHIhFQhL5SFAl4vLbhTwLPY+glIvI=; b=nVIq+eBoEsCJuPI8qEYsvcVUMGw5pZvv7URZh2NXMa67siwPj44dAgEdLuIiszlqaCy9U +qQ8LkBtBNFaYqPBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1585674461; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=XQme6pU20IGvq/AHIhFQhL5SFAl4vLbhTwLPY+glIvI=; b=a5ydcKKdzUjL1BUxaDDK5s9RouO8cETb/KaJaXnd8wYpS7kXPzqFgNmtLE7/ubaR09ubi E8ywXkANCfaAMXHlmBgqAW3tvG4dSNbUDEPnJe06+6eU7y6EyJsrKgagQcLhGJytXlW2bYq pUXpWRWV/qa7+w4caNIp77BGnTNaTHB2zMro70w/j0LaGVnzzCa5eZ1zRxrhanmBP2VR7Hv SthMt30Tg7ydLV8qeSnXmJUc+GXpLG4gpJ05ZNkEhh+JGDM7sxvXzlp97mNNr5ScRsh1pqH mOByx6FGl1ALFkqYhn9lM8uKdnsZMWbyUCylFbcjQd1uNPpSYs7+ULGTLaYw== 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 F03D9F80042; Tue, 31 Mar 2020 13:07:40 -0400 (EDT) Date: Tue, 31 Mar 2020 17:07:38 +0000 In-Reply-To: <20200331165652.84C5916D54B5@ary.qy> References: <20200331165652.84C5916D54B5@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: Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 17:08:04 -0000 On March 31, 2020 4:56:51 PM UTC, John Levine wrote: >In article <3295240=2Evh5t8hYAJM@sk-desktop> you write: >>> If you want it to be a domain, the ABNF should say: >>>=20 >>> authserv-id =3D domain-name > >>> This is not strictly backward compatible with the current text, but >I >>> don't think I've ever seen an authserv-id which wasn't syntactically >a >>> domain name=2E >> >>I've seen bare host names used=2E I guess that's syntactically a domain >name=20 >>also, but might not be what you expect if you assume it's really a >domain=20 >>name=2E It probably doesn't matter=2E > >I don't see any reason to exclude them=2E We could do this: > > authserv-id =3D sub-domain *("=2E" sub-domain) > >Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI >mail=2E That does allow IP address literals=2E Do we want that? Scott K From nobody Tue Mar 31 10:36:57 2020 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 968C23A259F for ; Tue, 31 Mar 2020 10:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: 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 lzmTTYZ9Tn7A for ; Tue, 31 Mar 2020 10:36:54 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 28F213A259E for ; Tue, 31 Mar 2020 10:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1585676211; bh=OVYDJCwEys7tT6pWGgzDkb9PbjMy60Q1x25n3RSHHDw=; l=1198; h=To:References:From:Date:In-Reply-To; b=A3Ja69c4nkNKvtzst269eHs9DXSiPzCjFpS8yZ0xAhzUJvZ5+UE9GzeZmV5ykx/Fm HjZ9YsUptivzKJSkzWloERBuc9nV4Konhyjc8dGh/+8gz+q5Kz0ipBAs9S7FmG/qF7 pO5olISAZujJZafDzfphsHKrigwXdTxW6CeMh8O6CJNEQAf8iDngdnkv3bZEr 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005E837FB3.0000207A; Tue, 31 Mar 2020 19:36:51 +0200 To: dmarc@ietf.org References: <20200330212312.341EB16CFEA5@ary.qy> From: Alessandro Vesely Message-ID: Date: Tue, 31 Mar 2020 19:36:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.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] Definition of "value" in RFC8601 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, 31 Mar 2020 17:36:57 -0000 On Tue 31/Mar/2020 00:38:51 +0200 Murray S. Kucherawy wrote: > On Mon, Mar 30, 2020 at 2:23 PM John Levine wrote: > >> In article < >> CABa8R6tTPAtEyPRSGbWKafZVZ4u8v8sN1VpTpMLQCia2_+5zRg@mail.gmail.com> you >> write: >>>-=-=-=-=-=- >>> >>>Hmm, we didn't include this in RFC 8616 either, I could imagine that it >>>should be punycoded also, though it really depends on whether in 6532 or >>>5322. >> >> This is another mistake in the ABNF in 8601. The point of 6532 is >> that with the exception of Message-IDs, any header fields that used to >> be limited to ASCII can now contain UTF-8 printable characters. >> > > Does someone have a fix in mind that could be submitted as an erratum? The > intent was indeed to make the authserv-id either a plain old ASCII domain > name or an A-label which doesn't need quoting. I missed that RFC 6532 > didn't update "value", unfortunately. That seems to be an RFC 6532 Erratum. By allowing UTF-8 in MIME tokens, we preserve the spirit of RFC 6532, maintain that the definition in RFC 8601 is valid, and the headers reported by the OP turn out to be valid, as they should be, shouldn't they? Best Ale -- From nobody Tue Mar 31 10:44:05 2020 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 D8F2A3A25B9 for ; Tue, 31 Mar 2020 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 4Iel8UCJxz6Q for ; Tue, 31 Mar 2020 10:44:02 -0700 (PDT) Received: from sigil.arcsin.de (sigil.arcsin.de [46.38.233.110]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B403A08D1 for ; Tue, 31 Mar 2020 10:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-language:content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585676639; x=1587491040; bh=o46kqSbMyuREW0Aqr7NeFc0TV/TJmmRET8m eWLucpDc=; b=TgLvslbkG4Mtu2Yd+ZE3ZalZSaeNAw5ZKH7Sopb58qleizC54bs why9idJHAyQj/sVvtnB3SxHTRZCGVt14XJ26yeIUqpCnZWne0jZHEpcMl9mYxerJ YI53VlP5wPe2x5QhamhDsZ1TifrHp0h93l8KE+Jl87MeHemOgaCST4q4= X-Amavis-Category: sigil.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200331165810.6148016D54F4@ary.qy> From: Damian Lukowski Message-ID: Date: Tue, 31 Mar 2020 19:43:34 +0200 MIME-Version: 1.0 In-Reply-To: <20200331165810.6148016D54F4@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 17:44:04 -0000 > The intention in 8601 is pretty clear, even though the ABNF doesn't agree: Yes, the RFC says the authserv-id can contain UTF-8, but its author stated that he intended it to be "either a plain old ASCII domain name or an A-label". One does not need UTF-8 for that. If authserv-id were not > authserv-id = value but > authserv-id = token ; token from RFC2045 wouldn't the author's intent have been covered as well, without any reference to RFC6531/6532? Damian From nobody Tue Mar 31 10:56:06 2020 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 9F5A63A25F6 for ; Tue, 31 Mar 2020 10:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 CHhPLpX8CisB for ; Tue, 31 Mar 2020 10:56:03 -0700 (PDT) Received: from sigil.arcsin.de (sigil.arcsin.de [46.38.233.110]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163F43A25F5 for ; Tue, 31 Mar 2020 10:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-language:content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585677361; x=1587491762; bh=pLKguN7HPXWtr88qTrdyTAiObTi9ev12uX9 D6iyUbiY=; b=kT7NjGKmtMgkoMJwD4M5BPEUDP2KESUoWQ5LJLCqaln+0L05us3 Cagykq/uovwkPCMJabgjzRk1sg++zNaGlvtm8YFq2Mw9vPyrqFZe3Y7epyNcKOMq +8j99s4ADsUmWchmmLUHn5UwQeMZW6WQDrA7visQPwrU5uZdSRSBMbKo= X-Amavis-Category: sigil.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200331165652.84C5916D54B5@ary.qy> From: Damian Lukowski Message-ID: <75744c3b-bc2b-790e-a865-2bdd61ec3cc4@arcsin.de> Date: Tue, 31 Mar 2020 19:55:36 +0200 MIME-Version: 1.0 In-Reply-To: <20200331165652.84C5916D54B5@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 17:56:05 -0000 > I don't see any reason to exclude them. We could do this: > > autbserv-id = sub-domain *("." sub-domain) > > Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI mail. Does this mean that a parser would need to know if the message has been sent with SMTPUTF8 in order to pass or refute U-labels? From nobody Tue Mar 31 12:12:03 2020 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 1D7B93A2701 for ; Tue, 31 Mar 2020 12:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 YcC9QbHG62Wu for ; Tue, 31 Mar 2020 12:12:00 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 959CB3A26F5 for ; Tue, 31 Mar 2020 12:12:00 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id a6so20570346ilr.4 for ; Tue, 31 Mar 2020 12:12:00 -0700 (PDT) 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=z+jJMN+4MdUkA5Ar7jFDojNR5bbk/7dZC/sjsASaFCg=; b=M1c1TOQfZrRhFlPi6k6nkMCPKxKE2VzD+i2TNSsqYWx36JO+X6YhFUeiVHM44QTYZP JHs83RbwIfRLvOcsR1bFklO4WNaBZOq9OxOJ/1So/ICG/0LhYHtuzierKdo+pDghHNeU wviRqkPWbcP8OqhlrcBJd4x5vhw7ZGZISmyFM= 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=z+jJMN+4MdUkA5Ar7jFDojNR5bbk/7dZC/sjsASaFCg=; b=L9Mt8fxcT+WOiBVaSdZvQSM9NyQ5/Cs8QLd7CkypKK6pMUqavF3xSdR53HEWNDbfjv b92xjZNoAhhbcOIC6Hncj8qjjvLRbkQyzWvi8e9CqI8s/vtRz8P2zC6XEDMk0ojiZpzZ B9fnqDF97NWdlnIKYU2KHV4P62FO1EsDppaAWNbIZYuG/UcAEpPhxtO3sBkqs6I6s00e 4P+STDcbcHW+0ezGlY4cfU/dHz0q/Kje7+lHKTlLCF+nu+rHfkn0vsRfsTanL3Jf/MOc TsX4f4Fkc/tUrqD96oPTijzs3ZLAN/OIGl81zMC21GoiUcC9Bi45EcdnJRE9pz1yEyXk sSAg== X-Gm-Message-State: ANhLgQ2mtvOt6B6sLzFqG+vjyVNCZ+w7vS06nfJ1NiVNLJwTaeQFozct qZ8nOLBR3jzzGzqRxMVNC8RqMzO9TciKh828WkauslEKOpY= X-Google-Smtp-Source: ADFU+vsusad+/hZoOWbHSh4z+ReQdWRmd2HNkVEx6KmChMKun+xA8Jm5TzxAABRqaF5iz+qKdWUxWQnQn9hhpNrykxc= X-Received: by 2002:a92:d20e:: with SMTP id y14mr18546366ily.104.1585681919566; Tue, 31 Mar 2020 12:11:59 -0700 (PDT) MIME-Version: 1.0 References: <20200331165652.84C5916D54B5@ary.qy> <75744c3b-bc2b-790e-a865-2bdd61ec3cc4@arcsin.de> In-Reply-To: <75744c3b-bc2b-790e-a865-2bdd61ec3cc4@arcsin.de> From: "Kurt Andersen (b)" Date: Tue, 31 Mar 2020 12:11:40 -0700 Message-ID: To: Damian Lukowski Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008b00a405a22b572d" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 31 Mar 2020 19:12:02 -0000 --0000000000008b00a405a22b572d Content-Type: text/plain; charset="UTF-8" On Tue, Mar 31, 2020 at 10:56 AM Damian Lukowski wrote: > > I don't see any reason to exclude them. We could do this: > > > > autbserv-id = sub-domain *("." sub-domain) > > > > Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI > mail. > > Does this mean that a parser would need to know if the message has been > sent with SMTPUTF8 in order to pass or refute U-labels? > You don't need SMTPUTF8 to handle IDNs. --Kurt --0000000000008b00a405a22b572d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 31, 2020 at 10:56 AM Damian L= ukowski <rfc@arcsin.de> wrote:
> I don't see any reason to exclude them.=C2=A0 We could = do this:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0autbserv-id=C2=A0 =C2=A0 =C2=A0=3D sub-domai= n *("." sub-domain)
>
> Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI= mail.

Does this mean that a parser would need to know if the message has been
sent with SMTPUTF8 in order to pass or refute U-labels?

You don't need SMTPUTF8 to handle IDNs.

=
--Kurt=C2=A0
--0000000000008b00a405a22b572d-- From nobody Tue Mar 31 12:29:32 2020 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 3B01C3A0F34 for ; Tue, 31 Mar 2020 12:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 5DzVgUdylBTg for ; Tue, 31 Mar 2020 12:29:29 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D31C3A0F2E for ; Tue, 31 Mar 2020 12:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585682964; x=1587497365; bh=9x661ywOjD3ykkSY3lVEMWmrnI067AEG8nH +CUKluvc=; b=rT67pzdpFfNhJ8OrIhiK48DHRuek1ZEtO2WqHorrqc4CQ1vLaZT YF2e2YfujDDc7U5KarubAAa+2M6foMTxYwFFC3heFKGA1MNx0fWiuwNKc2svaPGN FwgQceHR3h9SyLKnzjroSg/tWOTa6iO4Pf9p6s4chASt1k0AcNcpv3Kw= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200331165652.84C5916D54B5@ary.qy> <75744c3b-bc2b-790e-a865-2bdd61ec3cc4@arcsin.de> From: Damian Lukowski Message-ID: Date: Tue, 31 Mar 2020 21:30:03 +0200 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] Definition of "value" in RFC8601 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, 31 Mar 2020 19:29:31 -0000 > > I don't see any reason to exclude them.  We could do this: > > > >       autbserv-id     = sub-domain *("." sub-domain) > > > > Where sub-domain is imported from 5321 for ASCII mail and 6531 for > EAI mail. > > Does this mean that a parser would need to know if the message has been > sent with SMTPUTF8 in order to pass or refute U-labels? > > > You don't need SMTPUTF8 to handle IDNs. I'm not sure if this answers my question. A parser for an ABNF grammar needs to know the grammar. If the grammar is not fixed but depends on external factors, the parser also needs to know the external factors. In EML files that external factor is unavailable. From nobody Tue Mar 31 17:00:08 2020 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 844303A0DB8 for ; Tue, 31 Mar 2020 17:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=igHJ6YPf; dkim=pass (1536-bit key) header.d=taugh.com header.b=DmFBOaN3 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 UeEqU4NK56oS for ; Tue, 31 Mar 2020 17:00:04 -0700 (PDT) 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 303343A0DBE for ; Tue, 31 Mar 2020 17:00:02 -0700 (PDT) Received: (qmail 21497 invoked from network); 1 Apr 2020 00:00:01 -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=53f7.5e83d981.k2003; bh=5frR76aAlEv52foqTJ8sON73AQT187guqn1ydlzWi6Y=; b=igHJ6YPfL+gpUfaMKUhXiTwud2dFH27oYELpT6aMJCxGWp0FHhW29ZzuH4zQBjMpN9OHUC3QuU3BWDPaFx/frGLLodMenX2ObLejK8ZKIrLxQiPA1X/XOr/48av9Z8NKYyC760ARJxCIEJMpiLximQv+4hWbULNJnmXa/tyXGIcCSm1jFfxbXdrirR5Ka03nkb4YWqBDX5n+hm8hrfORC4vtaXublftd1D97eAgOmQEQGUUAxfMlNAWVBVVBVeJ5 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=53f7.5e83d981.k2003; bh=5frR76aAlEv52foqTJ8sON73AQT187guqn1ydlzWi6Y=; b=DmFBOaN3A8GYzGbHG/LPWDJRW3QkGzuGoafcNTfbyu+nGVPv+doQzmJBUh7fiAw4uJvTjjSCZuxse40EF0nMDeJMW87sMOvkzyb4vdvn6Vh/iaoIu/BNLpvHg6bYme624o5639zjuJRMnoHp7y1mLg4MW0Z8TQawMKHuxfv/mt3nMHfdQIiWafWlyLuDRFPS9m/K7iyTZiADQ07ZvL10hs43REKnLwDPBZP2GikfqR6J3lERbYm08TthklPg1Op7 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 ESMTP via TCP6; 01 Apr 2020 00:00:00 -0000 Received: by ary.qy (Postfix, from userid 501) id CF67D16D8D0D; Tue, 31 Mar 2020 20:00:00 -0400 (EDT) Date: 31 Mar 2020 20:00:00 -0400 Message-Id: <20200401000000.CF67D16D8D0D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.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] Definition of "value" in RFC8601 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, 01 Apr 2020 00:00:07 -0000 In article you write: >>I don't see any reason to exclude them. We could do this: >> >> authserv-id = sub-domain *("." sub-domain) >> >>Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI >>mail. > >That does allow IP address literals. Do we want that? No, take a look at RFC 5321 and search for "address-literal". You'll see they're always an alternative to a domain. Sub-domain is trivial: sub-domain = Let-dig [Ldh-str] Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig R's, John From nobody Tue Mar 31 17:02:18 2020 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 D49F33A0DC5 for ; Tue, 31 Mar 2020 17:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=WbL68TsJ; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=T+FqxIGw 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 JEH5RPwaQ0iw for ; Tue, 31 Mar 2020 17:02:15 -0700 (PDT) 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 0A9403A0DC3 for ; Tue, 31 Mar 2020 17:02:14 -0700 (PDT) Received: (qmail 21947 invoked by uid 100); 1 Apr 2020 00:02:14 -0000 Date: 1 Apr 2020 00:02:13 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=55b3.5e83da06.k2003; i=news@user.iecc.com; bh=0oLJkSovWLhknHofegtfNgAirn0DKyXiVortnv0sja4=; b=WbL68TsJqW8GY3iEHfYKP2D3fUmxzXJs8QOJZ9XT2fq/h5RDWeowm43TZ5lHh+0KnVaZTAR+LsSR94UellZWDJurOhszZgbMqj6e5pcnGiRhtY3+i9l2dt0QmY5O/0hvVUYnrwLMVIwiCIbMTa5zJm62MMX2O7RockCJgucbvgyEL0qaEfNYn1aQUUsrv+Z5Il6VXLFjwiKqd8EZecMcNQyNVKRJ19rOn+1o4G5wL7bcyeFDMy6nZZi7CQyMo2jY DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=55b3.5e83da06.k2003; olt=news@user.iecc.com; bh=0oLJkSovWLhknHofegtfNgAirn0DKyXiVortnv0sja4=; b=T+FqxIGwCQ+Oy7SxNf5MEaL2ieQyQBKRpG3PEYej0Ph8l5dYpyE5H9cxsiJwiP8uP5k4WPg61OSmen25Mwquk48/SrlYErpsr8Y0ob2aYXVArKWLUK5M17r/ApqecfneOEzW3qD2lXvKWgULx+4GEny3/SWZ+lp4JG0w6idDmUTxUXxXtz5d7oZoWYEy0NhWEplqPAqa0/rP00KcIm3o0lQpSzOBDPL8Oq9zGZLRoCIpmnFyy9r0d+8s1vu5lPPH Organization: Taughannock Networks References: <20200331165652.84C5916D54B5@ary.qy> <75744c3b-bc2b-790e-a865-2bdd61ec3cc4@arcsin.de> In-Reply-To: <20200331165652.84C5916D54B5@ary.qy> <75744c3b-bc2b-790e-a865-2bdd61ec3cc4@arcsin.de> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 01 Apr 2020 00:02:17 -0000 In article , Damian Lukowski wrote: >> Does this mean that a parser would need to know if the message has been >> sent with SMTPUTF8 in order to pass or refute U-labels? The definition of an EAI message is separate from SMTPUTF8. As a close approximation, any message which has an x80 bit set in a character in the header is an EAI message. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Mar 31 17:06:12 2020 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 798123A0DD8 for ; Tue, 31 Mar 2020 17:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=W/T8CrsK; dkim=pass (2048-bit key) header.d=kitterman.com header.b=CbQpZeHO 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 wdUtMe1bDXzK for ; Tue, 31 Mar 2020 17:06:07 -0700 (PDT) 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 0D1D03A0DD7 for ; Tue, 31 Mar 2020 17:06:07 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B38D4F80120; Tue, 31 Mar 2020 20:06:05 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1585699565; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=Z4rfQ4SZj1UWYIHvzwLJh7lL0fsJiT9S6HAEPEbgZng=; b=W/T8CrsKThcsQeNwX2XO1uRsIWT7jVIdRY4aX13EfsXVRlZe4sxnUk2l83iuBMxCNdjGp 687qjgo/NrzQpAnBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1585699565; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=Z4rfQ4SZj1UWYIHvzwLJh7lL0fsJiT9S6HAEPEbgZng=; b=CbQpZeHOEWgsXgDwVmTZsE9FiWX/jbRc5aAdtwOMLfgb1xbbqGxz25rwvYTS24b39+HJM x1Tiiw5Ib807UPKYQA/+lnFTDvrv9kHLWmXRu4VfIzZG3t+XTrXFaTVVKYWJaqZFy+M99hE Gbo8ZgqhKG3mKvhwRs4iuQ25/b7IBxAuQjw3wGN/eo7+YqR5Vam8wnFRoLKLghWvZGhY6YS mO81t+SdwxZNxq1E9AmYvYjiUbFbO7/dhReT6yZ/2XzxsSoTIVwbTtwTP3sX4SwtvlGDGtI yvd1Dl1wEcGwSxKcgMJpfVJPuJtAx/mkd1Fx8ZYxPo6yzLk0HUMPN05xz2Cg== 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 5A41DF80042; Tue, 31 Mar 2020 20:06:05 -0400 (EDT) Date: Wed, 01 Apr 2020 00:06:02 +0000 In-Reply-To: <20200401000000.CF67D16D8D0D@ary.qy> References: <20200401000000.CF67D16D8D0D@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: <442E06B4-79FE-4AA9-A6D8-C36C28F9C3BA@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 01 Apr 2020 00:06:10 -0000 On April 1, 2020 12:00:00 AM UTC, John Levine wrote: >In article you >write: >>>I don't see any reason to exclude them=2E We could do this: >>> >>> authserv-id =3D sub-domain *("=2E" sub-domain) >>> >>>Where sub-domain is imported from 5321 for ASCII mail and 6531 for >EAI >>>mail=2E >> >>That does allow IP address literals=2E Do we want that? > >No, take a look at RFC 5321 and search for "address-literal"=2E You'll >see >they're always an alternative to a domain=2E Sub-domain is trivial: > > sub-domain =3D Let-dig [Ldh-str] > > Ldh-str =3D *( ALPHA / DIGIT / "-" ) Let-dig Odd=2E In RFC 6376 it's: domain-name =3D sub-domain 1*("=2E" sub-domain) ; from [RFC5321] Domain, ; excluding address-literal I wonder why it excludes address-literal if they are already excluded? Scott K From nobody Tue Mar 31 17:11:41 2020 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 969733A0DE8 for ; Tue, 31 Mar 2020 17:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ruBMd1kK; dkim=pass (1536-bit key) header.d=taugh.com header.b=UA/roSMP 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 vo3oG1J27tVt for ; Tue, 31 Mar 2020 17:11:39 -0700 (PDT) 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 E75FB3A0DE7 for ; Tue, 31 Mar 2020 17:11:38 -0700 (PDT) Received: (qmail 23220 invoked from network); 1 Apr 2020 00:11:37 -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=5ab2.5e83dc39.k2003; bh=4yefw62ZRwH0OvAlC5YhvGVNBzLxstn1bvEr2ZFsZqs=; b=ruBMd1kKU96qf4LLg1Nj1TiEMlSdEM/y+oN+mq9JoYRxFOt4Ohj1TK7X7YvBTT+GajcE71GI904i9IX3W2XdXc6j0ItX6ii/f0LkvxzRpuQuIXzaTsFgVHa7znNQxjOUWwueofZOSCCsMWvZtOAj1yLsXedqbOfbskLWb6hvztQ5dJoujkWHbiQexj2+jWmJrXhpTbnaYQJYWtFVNItLElfWtXn4tdh+pYGiubDvhI0ZGwZowkboatxMPInTKumE 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=5ab2.5e83dc39.k2003; bh=4yefw62ZRwH0OvAlC5YhvGVNBzLxstn1bvEr2ZFsZqs=; b=UA/roSMP+WlwfBEo71GlW35oyoDt+LRIJdDv5XH/NAxKWoFgDu3FtErUdThABpTP6paoal9i7MpPgcl+Kfp9djst2lP0GrgW1+L8PCIwM2rQ+V2iLSpndDLfn8uIkiyrpW/uDAok1Gpsz7iIKmx41NbEiuF0c8zpKFMI0GEYBPMHYl9fG6HVwIb+M7/ohd+iB70KAus1aylDVkHvjfuCv07yIAxc0GC+fHCOYG9dOyl+ca/5zPEcWjeSqY0IVPPu 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 ESMTP via TCP6; 01 Apr 2020 00:11:37 -0000 Received: by ary.qy (Postfix, from userid 501) id 6571D16D8E16; Tue, 31 Mar 2020 20:11:36 -0400 (EDT) Date: 31 Mar 2020 20:11:36 -0400 Message-Id: <20200401001137.6571D16D8E16@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de 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] Definition of "value" in RFC8601 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, 01 Apr 2020 00:11:41 -0000 In article you write: >> The intention in 8601 is pretty clear, even though the ABNF doesn't agree: > >Yes, the RFC says the authserv-id can contain UTF-8, but its author >stated that he intended it to be "either a plain old ASCII domain name >or an A-label". One does not need UTF-8 for that. If authserv-id were not > >> authserv-id = value > >but > >> authserv-id = token ; token from RFC2045 > >wouldn't the author's intent have been covered as well, without any >reference to RFC6531/6532? You'll have to ask Murray what he meant, although as we've seen section 2.5 specifically says that an EAI authserv-id "may be expressed in UTF-8." In an EAI message, an A-R header has to allow UTF-8 characters in mailboxes, so it might as well allow them in other places including domain names and the authserv-id. R's, John PS: for anyone who might suggest one could "punycode" a mailbox, don't even think about it. From nobody Tue Mar 31 23:21:20 2020 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 EE92D3A0D45 for ; Tue, 31 Mar 2020 23:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=arcsin.de 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 waqjh1GAKKmU for ; Tue, 31 Mar 2020 23:21:15 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04E73A0D43 for ; Tue, 31 Mar 2020 23:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585722064; x=1587536465; bh=Rg+j0bGMIAJH0Soe1qcWy6XfWhxH6c/INFd LYuf1cX0=; b=Rr9OMvbp52UxW8+wnLtYz/82u/1H8Rr4fx3lM9DjE8EaJYJiQcc y3WbovuKqwFM4+q8l+Bn1hRnTXnO/NyqEgX9OYGq2n4QJ71EnmkxrFk/SanN55eg 4a5Ih1ADpiL1Y/Go6LX88YN7DHcDJZ56T1qE079iTIBjAhaz+uZJPFY4= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200331165652.84C5916D54B5@ary.qy> <75744c3b-bc2b-790e-a865-2bdd61ec3cc4@arcsin.de> From: Damian Lukowski Message-ID: Date: Wed, 1 Apr 2020 08:21:43 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 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, 01 Apr 2020 06:21:17 -0000 > authserv-id = sub-domain *("." sub-domain) > ; Where sub-domain is imported from 5321 for > ; ASCII mail and 6531 for EAI mail > As a close approximation, any message which has an x80 bit set in a > character in the header is an EAI message. As the authserv-id is part of the header, this boils down to: "If the authserv-id is UTF-8, then it might be UTF-8" This seems equivalent to > authserv-id = sub-domain *("." sub-domain) > ; Where sub-domain is imported from 6531 for > ; any mail