From nobody Sat Jun 1 01:13:37 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866A120163 for ; Sat, 1 Jun 2019 01:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70jI8LmiBbZf for ; Sat, 1 Jun 2019 01:13:34 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 8632D120072 for ; Sat, 1 Jun 2019 01:13:34 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id d7so232273lfb.10 for ; Sat, 01 Jun 2019 01:13: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=kO8pISvmXVUgAGJ57NA0XOSBrV/HfF2nUdRpBGbp4QQ=; b=CI8HcKtFFSRGdHjgeSleZ3aspnxNRb4aWO3zmMa08pjX5Hr1HzV4R1W9GaDIIr+swU sE7ZGRebuDln6G6KIKxDTmoQc5Q8w5WvyPCWUSpmEHVTvIuBDrMm0S0T4QRNDvbC8Uq4 90n6xQWeM6RoaI/DrDLNPm4i4HzOj5fO0IvKW4xhAOd5ehE4QDYyZzl9a13lhs6KQu8k ZjtDwGNXuGqoV+ZS7IZ72VUXU8HTwRHN1avdDRFavx0/POSMh8sk4RVmoeEeCSjtciQt fXGWswIJaRUEx7WH+2oMcptKzNGEZLkB8MwYerZDymfKyolwQ/zjjGzuj5Ots1vuXh1/ jkdQ== 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=kO8pISvmXVUgAGJ57NA0XOSBrV/HfF2nUdRpBGbp4QQ=; b=rTRRB0AbIRBhDgtu3qmM79bdJ7VjND0EulPKk0zWQjiCtvgcN/701u8cAo5ikzOsPw FnH24xeeQ3DR7RsS+QV3MuuIKv0o1UwOOw5nCdv2snil8RmQR8NJ3mC/gE2sGnJnxthe mLy7Dtb6dO25jVo5usHYtnnifohux9TN+mH/bI21pMUaezZ569Cdup/NHcXdQQNHnxOs jnogWOGSrC+W6vmpGo2Cdg5imSUAzZE+wqUDNd/9SdFaFoWKuYgV+O3KFXy0Aq/DPUVA /keoSvbsWRB9KvQHAfwYYe0gxWAV3xzhtdERGWj0kquna45htMx8kN0zpvibiID+w0Uz nKwg== X-Gm-Message-State: APjAAAVUDL1KbJHSlGBIG7nGKxEHukGGMeAjtVPGTN5iDo6ZcpzfYIys 67QGOz6YxtHzDrhSv1LIGxjElMzVL7kR8SsadBs= X-Google-Smtp-Source: APXvYqw5qPxu/DSmf3THwaWkaB76Lo1LjWhslSVjvlAikq6XKcDw9spjCVzfGkcgMOQ0aZWcunZCOUTyY3ROjE34TvI= X-Received: by 2002:a19:ab1a:: with SMTP id u26mr736340lfe.6.1559376812713; Sat, 01 Jun 2019 01:13:32 -0700 (PDT) MIME-Version: 1.0 References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> In-Reply-To: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> From: "Murray S. Kucherawy" Date: Sat, 1 Jun 2019 01:13:18 -0700 Message-ID: To: Dilyan Palauzov Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fe4097058a3eb4fb" Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 08:13:37 -0000 --000000000000fe4097058a3eb4fb Content-Type: text/plain; charset="UTF-8" On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov wrote: > Shall I submit an erratum to RFC7489? > I would, yes. And this should certainly be recorded as something we need to fix for standards track DMARC, whether by chasing down RFC7489 errata or via a dedicated issue in this WG's tracker. -MSK --000000000000fe4097058a3eb4fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 31, 2019 at 10:55 AM Dilyan P= alauzov <Dilyan.Palauzov@ae= gee.org> wrote:
Shall I submit an erratum to RFC7489?
=

I would, yes.=C2=A0 And this should certai= nly be recorded as something we need to fix for standards track DMARC, whet= her by chasing down RFC7489 errata or via a dedicated issue in this WG'= s tracker.

-MSK
--000000000000fe4097058a3eb4fb-- From nobody Sat Jun 1 01:22:58 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D971201D9 for ; Sat, 1 Jun 2019 01:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net 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 1OiaQ-J6DhDj for ; Sat, 1 Jun 2019 01:22:55 -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 6546B12004D for ; Sat, 1 Jun 2019 01:22:55 -0700 (PDT) Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x518KdlS006348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Jun 2019 01:20:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559377252; bh=qOq+YzSY65SF3BviTvXfEIvdqiMm4SOL2UoTO51hNnA=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=VGAlBCUHqJp55VThQuGBlV8+ULu+cYyw0yRlPbORsPR/9kV77uqrwF8vvvT2NEGvp a320eyrGs1C5EpFnibwN9iqK1BlKm1jGrVUKJ5xpJbEawkjGvw7jn7kv4e27M97tBZ 1wABKk5iC46mFh5KAb+kNX3D0mxWGknvyeKzno9I= To: "Murray S. Kucherawy" , Dilyan Palauzov Cc: IETF DMARC WG References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> Reply-To: dcrocker@bbiw.net From: Dave Crocker Message-ID: Date: Sat, 1 Jun 2019 10:18:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 08:22:57 -0000 On 6/1/2019 10:13 AM, Murray S. Kucherawy wrote: > On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov > > wrote: > > Shall I submit an erratum to RFC7489? > > > I would, yes.  And this should certainly be recorded as something we > need to fix for standards track DMARC, whether by chasing down RFC7489 > errata or via a dedicated issue in this WG's tracker. Hmmm... The formal rule for errata in the RFC system is rather constrained: Only errors that mis-specify what was intended are permitted. So, errors in thinking or failures to provide for cases don't count as errata. What this means is that there is no standard way to record the need for better-performing capabilities or addition of new capabilities or the like. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 1 02:01:14 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024EC120222 for ; Sat, 1 Jun 2019 02:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=qASsMkcc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t/GJ6UL8 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 qrX_JZaxe0UL for ; Sat, 1 Jun 2019 02:01:10 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EA11201D1 for ; Sat, 1 Jun 2019 02:01:10 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 99F3321FFD; Sat, 1 Jun 2019 05:01:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sat, 01 Jun 2019 05:01:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=h HcJPEiOPJDu+WIfCGUfPfG1jGKGhXRzeMO9Vg5kdKg=; b=qASsMkccyPgwuQevw h7tU5kK19NU/D3+rgFaZuxRswHS5wDZPi2tdb+kW23B/39S+vN2H+BnEFkyyUr9r QVD3LUg6AWSTAqk78yApyhRRA+htTMA0u4sKei6E5uPle/wbHWDwSgdCxVkzkp/V NMYftlvU+LVlDPhzVjnorfHzn2/pqJb2Z70h2IC/hgeJVnBiAOEcBbXZTqMnJ9oN Pb2tknc2j2xcab66AismhZeBK0moVMqJ9/wBmnIydYsaO+d8cOvpJD70OaFjBADn GmGd2zCsLGwuRa33DmiBlwQCcaioq+oy/jcLMlq5ZUAAUHX2yOFx1aEEtbZaZlTF Mb2uQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=hHcJPEiOPJDu+WIfCGUfPfG1jGKGhXRzeMO9Vg5kd Kg=; b=t/GJ6UL83P+vJQBCWRCLXavNoyp5yXU2PRVGDo7VWU6M8dBNn2MG+Cngj lHdkH86WLhG3O/wYLF8m+qMkxRtKeG6yPvq1SlPQZ7tA1gplMBq/J5TLKewjbvY1 K+n2PyeisGzFxmKFVeoUtHseHII2zpVV/G/kbVz1PmMvVG/QqnrquoKJl51CwS2n 7TkdklmdLSmEc81V7QuzBzgjD+0eDaULV5FsjggVyvdOSFXgv+Izcaoo9xaIxfmL AtlFWA6zOWJSxtbDJKppwvBu5Onge7E3765t3DSslD95ih+7fWGw74ZBo9YdzNaz 66oRiMJTugJDIwqg77e57og4wGVrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeffedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhofgjfffgkfhfvfesthhqmhdthhdtjeenucfhrhhomheptehlvgig vgihucfovghlnhhikhhovhcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh eqnecuffhomhgrihhnpehivghtfhdrohhrghdpsggsihifrdhnvghtnecukfhppeejjedr leejrddugeehrdehheenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkoh hvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.0.12] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F80080059; Sat, 1 Jun 2019 05:01:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Sat, 1 Jun 2019 10:00:59 +0100 Cc: "Murray S. Kucherawy" , Dilyan Palauzov , IETF DMARC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> To: dcrocker@bbiw.net Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 09:01:13 -0000 Hi Dave, > On 1 Jun 2019, at 09:18, Dave Crocker wrote: >=20 >> On 6/1/2019 10:13 AM, Murray S. Kucherawy wrote: >> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov > wrote: >> Shall I submit an erratum to RFC7489? >> I would, yes. And this should certainly be recorded as something we need= to fix for standards track DMARC, whether by chasing down RFC7489 errata or= via a dedicated issue in this WG's tracker. >=20 > Hmmm... >=20 > The formal rule for errata in the RFC system is rather constrained: Only e= rrors that mis-specify what was intended are permitted. >=20 > So, errors in thinking or failures to provide for cases don't count as err= ata. You are right, but I can always mark this issue as =E2=80=9Chold for update=E2= =80=9D, so that it can be tracked for the -bis document. Best Regards, Alexey >=20 > What this means is that there is no standard way to record the need for be= tter-performing capabilities or addition of new capabilities or the like. >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Jun 1 08:38:53 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865E5120152 for ; Sat, 1 Jun 2019 08:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18FHZGnE9s5a for ; Sat, 1 Jun 2019 08:38:49 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159EA12004F for ; Sat, 1 Jun 2019 08:38:49 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id l26so10284977lfh.13 for ; Sat, 01 Jun 2019 08:38:48 -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=VXcXk0Fnc51+PqporeL4Qc1Ocb9BTQb9RYDKAizukPc=; b=X3U58Ec35y+v3D1B+mMrVmSRL/+Jbd58IaxFZtjp/b76h0FcgS5dydGw4u5Pk0xO36 a9lz6wIm9b3uKT1n6S5vZxUr+dtvfiqhzwFSz+rGNHJ3XMIaimv8g0mH9eWJFJ01ybCW TcT1itYbUxgb/ev/w2zw3l97WAXxoe8Yj57fLth4jxt6wcQiFrebuRE2dz2LwhkcLEEC cEZKes1G7PrcKd210eIvNGmaTwN1M4GcOBNinh0qWlkGoWGs2k/FNBhTYrLoj4RQryOS +d6oXKFlkgh9ux746ZfeRYuJUvXd1psC1z4uiI7mzfF/vU0YN9Ilxt1Y4Z2vdSfbUS/S f23g== 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=VXcXk0Fnc51+PqporeL4Qc1Ocb9BTQb9RYDKAizukPc=; b=idKPpo9Lt/HcPU9B0AkCMa0RcH5DTO9HLsO/WRKCMjYoPAINt9cHmF3kuZKtWoJQGZ O4BcnxELSl62roiGf6qJxa7ecSMC3eu81u9pr5MMAww9Vwz2qFJ4O5cZuvohQFhJ66wR 1Hv7grpCC6m2uHlUM8zUegbG7u6Y468PEYSp29V5V2AzR5ugZjiNvgQoF4e99TRQ/l+5 RJXWDbgvDGm3Kyr57DTtLmbXuI/1saQ1qYnFwys20szXUB0lrzTAsHTK23XSfFv/Q3bM LuBVL4OB+LBuvQQBmV7j0CqOkFPdyexUP1saXEiSbM1wKGyYSgguKkcTPyXSGVpzrp40 hNyw== X-Gm-Message-State: APjAAAVXgt7y6OD3QhdHieMeFviZ6aJ3dv++XM977e9PIYf6MvGkqSnU PWSy1lfvsKioac6CiibbdwcvaMf4mHYV8XSxVQQ= X-Google-Smtp-Source: APXvYqyGXa8GAGfOTEJkj9hxQERrv0jIQi7Vgum1aUASjxyaqn+FJtqPlrg04/3LXkBWU14RcRU4pIBE/MTi6QwCV1U= X-Received: by 2002:a19:ab1a:: with SMTP id u26mr1569568lfe.6.1559403527226; Sat, 01 Jun 2019 08:38:47 -0700 (PDT) MIME-Version: 1.0 References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 1 Jun 2019 08:38:32 -0700 Message-ID: To: Alexey Melnikov Cc: Dave Crocker , Dilyan Palauzov , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004d4a09058a44ed57" Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 15:38:52 -0000 --0000000000004d4a09058a44ed57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 1, 2019 at 2:01 AM Alexey Melnikov wrote: > > On 1 Jun 2019, at 09:18, Dave Crocker wrote: > > > >> On 6/1/2019 10:13 AM, Murray S. Kucherawy wrote: > >> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov < > Dilyan.Palauzov@aegee.org > wrote: > >> Shall I submit an erratum to RFC7489? > >> I would, yes. And this should certainly be recorded as something we > need to fix for standards track DMARC, whether by chasing down RFC7489 > errata or via a dedicated issue in this WG's tracker. > > > > Hmmm... > > > > The formal rule for errata in the RFC system is rather constrained: Onl= y > errors that mis-specify what was intended are permitted. > > > > So, errors in thinking or failures to provide for cases don't count as > errata. > > You are right, but I can always mark this issue as =E2=80=9Chold for upda= te=E2=80=9D, so > that it can be tracked for the -bis document. > My understanding matched Dave's originally, but then I found this: https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ It's not surprising this sort of need to record a deficiency for later handling has come up before, and we've adapted a way to deal with it. -MSK --0000000000004d4a09058a44ed57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 1, 2019 at 2:01 AM Alexey Mel= nikov <aamelnikov@fastmail.fm<= /a>> wrote:
> On 1 Jun 2019, at 09:18, Dave Crocker <dhc@dcrocker.net>= ; wrote:
>
>> On 6/1/2019 10:13 AM, Murray S. Kucherawy wrote:
>> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov <Dilyan.Palauzov@aegee.org= <mailto:Dilyan.Palauzov@aegee.org>> wrote:
>>=C2=A0 =C2=A0 Shall I submit an erratum to RFC7489?
>> I would, yes.=C2=A0 And this should certainly be recorded as somet= hing we need to fix for standards track DMARC, whether by chasing down RFC7= 489 errata or via a dedicated issue in this WG's tracker.
>
> Hmmm...
>
> The formal rule for errata in the RFC system is rather constrained: On= ly errors that mis-specify what was intended are permitted.
>
> So, errors in thinking or failures to provide for cases don't coun= t as errata.

You are right, but I can always mark this issue as =E2=80=9Chold for update= =E2=80=9D, so that it can be tracked for the -bis document.

My understanding matched Dave's originally, but th= en I found this:

It's not surprisi= ng this sort of need to record a deficiency for later handling has come up = before, and we've adapted a way to deal with it.

-MSK
--0000000000004d4a09058a44ed57-- From nobody Sat Jun 1 10:54:28 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B84F120167 for ; Sat, 1 Jun 2019 10:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net 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 9Gb6d1zHB6rE for ; Sat, 1 Jun 2019 10:54:24 -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 568C41200FE for ; Sat, 1 Jun 2019 10:54:24 -0700 (PDT) Received: from [192.168.0.125] (178-164-174-220.pool.digikabel.hu [178.164.174.220]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x51Hq7RZ020097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 1 Jun 2019 10:52:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559411530; bh=WhSe6twbiUWe7wFcx/Ih5GVQBmc/zhyRK8LoQ6Pt20U=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=fKJNGQ7d6MMBqS4sOWhNBtdcN30OUwMONsqxDZ7VcM59XV7b+Tp6TDPZX4g+i1+4g vVNRyfuM03g3LeufCBv84DEes3+v3zafShoBjadC20IkYKRwZwrBPHKT3yz5kXgY/i p0al5W+saUTcN5pAMW3rU5engYjGq3+zFJEQ7rgQ= To: "Murray S. Kucherawy" , Alexey Melnikov Cc: IETF DMARC WG , Dilyan Palauzov References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> From: Dave Crocker Reply-To: dcrocker@bbiw.net Message-ID: <32202ca2-6ed4-8c48-dad2-82893601dd95@dcrocker.net> Date: Sat, 1 Jun 2019 19:49:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 17:54:27 -0000 On 6/1/2019 5:38 PM, Murray S. Kucherawy wrote: > My understanding matched Dave's originally, but then I found this: > https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ Interesting. I've never seen that before. I suspect few others have. I was educated on the model I described by having a design change -- I don't remember whether it fixed a design error or added an enhancement -- refused for the errata record and I was told errata were only for documentation errors -- that is for cases in which the document did not adequately described "what was intended". So, anything that alters what was intended by the wg and/or authors was declared out of scope. While this was some years ago, I'm quite sure it was long after the date of the IESG document. FWIW, it strikes me as a little crazy to have errata admittance rules be different for different streams. What is the possible benefit that is major enough to warrant the additional complexity? But that's just me. Taking the current case, while it's nice that Alexey is friendly to adding this item as a hold, I'll suggest that the decision should rest with the troops already tasked with assessing the submission. There doesn't seem to be a good reason to require an AD to make that decision. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 1 13:00:58 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B801A12011E for ; Sat, 1 Jun 2019 13:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_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=isdg.net header.b=Zw5VTFak; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=TnjEpIiz 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 1VQ-Ipgsfsx6 for ; Sat, 1 Jun 2019 13:00:53 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E7B2E1200D6 for ; Sat, 1 Jun 2019 13:00:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=886; t=1559419247; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=QCISx8DjF8nekIsruf+STCp59A4=; b=Zw5VTFakwp7Z1eTMKFnV473olI8lBVtYxABcYH95PI1r2F3v+UGN42pD9qYRc8 fsqUez9MlSMflBJa+A80ImXtlTvarMgdNEoT42keW5q6lNQLHtE0M6mnXx9BCni4 jG+97Y+mN8o0+kml/suirXxEIZWTgdNZMCx3zpV9ypiPQ= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 01 Jun 2019 16:00:47 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 211695682.58212.3136; Sat, 01 Jun 2019 16:00:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=886; t=1559419067; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ot0MVez WdQsoqdh19jUOz57uW3L3fG8poZ9r2HNKvz8=; b=TnjEpIizQfNNxd3Ej6J5DXD g2H8h8SUltKC/1VQ7Xft2/khafMO8GcV7UNqwLJPAd8GyopY/ONp/1L8moSuWP1r asrxAfb8xe6paqnFP1Vn+2/+Va277kSWNI9wE2xkdyfxYFJsi/DnEIXU3GWkVqMM zybckIIefIqZygt+JuZM= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 01 Jun 2019 15:57:47 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1783922910.9.360592; Sat, 01 Jun 2019 15:57:47 -0400 Message-ID: <5CF2D972.9050404@isdg.net> Date: Sat, 01 Jun 2019 16:00:50 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 20:00:56 -0000 On 6/1/2019 11:38 AM, Murray S. Kucherawy wrote: > My understanding matched Dave's originally, but then I found this: > https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ > > It's not surprising this sort of need to record a deficiency for later > handling has come up before, and we've adapted a way to deal with it. > Interesting. How does this change based on the document status? Would you care if its informational? Normally, you would not? But DMARC has broke the mold. We seek an IETF standardization of a DKIM Policy system. We need to finish this work. Right now, the DMARC method has the attention. There is going to be lots of work here and unless the 3rd party question is addressed, I expect the same ADSP scrutiny for DMARC. I agree any suggestions for Informational Status document change should be held for the PS work. -- HLS From btv1==0578190657c==fosterd@bayviewphysicians.com Mon Jun 3 06:57:15 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F294912023E for ; Mon, 3 Jun 2019 06:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 s6M0FEUI4tYC for ; Mon, 3 Jun 2019 06:57: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 2CA3F120222 for ; Mon, 3 Jun 2019 06:57:13 -0700 (PDT) X-ASG-Debug-ID: 1559570230-11fa3116c82ba9b0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id iCAeiNEHO8OBWa7t (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 03 Jun 2019 09:57:11 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client 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=D9KpZcCuAR2YG0tBLYYzW8WEwUHB3592pNsueWXNq0Q=; b=LG6UkCJNiLd0vflzabrA3D2t9aQNYFb+YCPfGBXa7zrijbIReN1kiNihO/7yeHRqw LBWWueK0E2bDIT2OMiBx1YDla8yx/xQGPUA6eiUGSm+owxVHYRigiIOFbpfWVU9Vf zlONe0i5Y9X3OLYi6Im/F0xkScBKbYMqEu/nEqDp4= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 3 Jun 2019 09:57:02 -0400 From: "Douglas E. Foster" To: Date: Mon, 3 Jun 2019 09:57:02 -0400 X-ASG-Orig-Subj: Mandatory Sender Authentication Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=d261a4af988142feb0e8de7196c97574 X-Originating-IP: [192.168.72.245] X-Exim-Id: e5ee6809b78b45ea937105f86d84f499 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1559570231 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: 4016 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: [dmarc-ietf] Mandatory Sender Authentication 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, 03 Jun 2019 13:58:56 -0000 This is a multipart message in MIME format. --d261a4af988142feb0e8de7196c97574 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Our real goal needs to be mandatory sender authentication. Any secure email gateway must go through these steps: Source Analysis: Filter message from unwanted sources Sender Authentication: Filter messages that are attempting impersonation Content Analysis: Filter messages with unwanted content Content filtering always requires exceptions, and those exceptions are granted based on the sender. Such exceptions are only safe and appropriate if the sender is verifiable. If the exception is applied to an unverified sender, it is possible for a spamming impersonator to gain the elevated trust and reduced filtering which was only intended for the trusted sender. So Sender Authentication needs to become mandatory: Senders MUST implement SPF or DKIM, and SHOULD implement both. Although the MX list becomes a default SPF list for those who do not publiish a policy. MTAs MUST ensure that DKIM signatures remain verifiable. If they are unwilling or uinable to do so, they should reject the message with a PermError. Forwarders MUST either forward with breaking DKIM signatures, rewrite messages under their own identity, refuse the message, or discard the message as spam. IETF MUST provide a way for intermediate systems (both spam filters and list fowarders) to insert content under their own signature, without breaking original signatures. This will have implications for MUAs. Sure it will be hard, but has this not been what you have been trying to achieve for 15 years? SPF and DKIM provided the enabling technology, but they were deployed as sender options. Doug Foster --d261a4af988142feb0e8de7196c97574 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Our real goal needs to be mandatory sender authentication.   = ; Any secure email gateway must go through these steps:
  1. Source Analysis:  Filter message from unwanted sources
  2. Sender Authentication:  Filter messages that are attempting imper= sonation
  3. Content Analysis:  Filter messages with unwanted content
Content filtering always requires exceptions, and those exceptions are= granted based on the sender.   Such exceptions are only safe and= appropriate if the sender is verifiable.    If the exception is = applied to an unverified sender, it is possible for a spamming impersonator=  to gain the elevated trust and reduced filtering which was only inten= ded for the trusted sender.
 
So Sender Authentication needs to become mandatory:
  • Senders MUST implement SPF or DKIM,  and SHOULD impleme= nt both.  Although the MX list becomes a default SPF list for those wh= o do not publiish a policy.
  • MTAs MUST ensure that DKIM signatures remain verifiable.  If they= are unwilling or uinable to do so, they should reject the message with&nbs= p;a PermError.
  • Forwarders MUST either forward with breaking DKIM signatures, rew= rite messages under their own identity, refuse the message, or discard the = message as spam.
  • IETF MUST provide a way for intermediate systems (both spam filters an= d list fowarders) to insert content under their own signature, without brea= king original signatures.    This will have implications for MUAs= .
Sure it will be hard, but has this not been what you have been trying = to achieve for 15 years?  SPF and DKIM provided the enabling tech= nology, but they were deployed as sender options.
 
Doug Foster
 
 
 
 
 
 --d261a4af988142feb0e8de7196c97574-- From nobody Mon Jun 3 07:12:32 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74AE120251 for ; Mon, 3 Jun 2019 07:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1ed23Th6gprB for ; Mon, 3 Jun 2019 07:12:28 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 997E912024F for ; Mon, 3 Jun 2019 07:12:28 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id n2so8349675pgp.11 for ; Mon, 03 Jun 2019 07:12:28 -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=cNzgDHaoiXjAGtsBB+cfD6cB7TxhhQsRD3+0+RWoGj8=; b=rUlLOmlpoDD4YNW2Pm+J9uBQFmUi8FhMRG39lq2AnLR4u0uGZISWpmuXI+8uJLl2ht 4s+3MDba9UbCn3uW6/Bz6A5Sb4LMHRMvhVf1MNYuZh4eW3d/3mOZDyiEbyd9r7ScgljV y3bE+W7PtIoA6/mp9pUytKSxNhWr4hEihgz2KDPX0ibUKIjpiIBwfW/0bljfguFPuLiv 7MRL89ROKXlmjMPl2oVYkd/dTeKnk+3W8hvasA32Ezu5o6N2z+z1IitOsBeF+bhycdsZ 2slFd1/msmhymM+NQMcP/+jigmdD/gwU0Vf+QIMlBvz7knhk5pLeVbx6/Ex636XV5XxP Nl8A== 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=cNzgDHaoiXjAGtsBB+cfD6cB7TxhhQsRD3+0+RWoGj8=; b=iHRi9lriQqJw2XpeZPk9XQUin7WzFcUVaaeHFL4xEh0kzSgmggvfqBwgi+z7P/mMFO YKKVqE1LAHXfMfZlyR18br0rB47G9vqyBBCELKRe5IcoeMLo0rh1n08V1ONG1SajfKEx 5Z2Dfm16Hp0Zm5ZdADFevrx2xh48Jyr5IuJf2qD23RGvf+CNDMU7MNnaJgpN/BGM+wrF +So2G+fLbELmA6QWRIT/4OeXKsNlGe4eGdREwL/+gG7cVW0PK7QCKKF3c4vCpOxilfOX jrV8RBCBo1pUvcsBipTDH4Tl1XDfJBYw+BC+jBCQnRDj6dQSDeTYQQpfgGsRrGMcm5Dn SP7Q== X-Gm-Message-State: APjAAAWRa8zCVyWIEvh1mE4S2M52trRpRnIevL8M+9SZrlth5mHRWymF 4Z/9+G5q0k4I6bGXAb25xG6X86Vn9hMJCIzl9bdPsqLPUNX136FI X-Google-Smtp-Source: APXvYqwAO+2tAgkq57xL8jJZs3TmGrqoRBlGVki5fd2+48quWQthK/KJck8q9kIHkOYGDZG2Ct9XirAPFIf5zYYlGNQ= X-Received: by 2002:a63:f44f:: with SMTP id p15mr28335763pgk.65.1559571146719; Mon, 03 Jun 2019 07:12:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Mon, 3 Jun 2019 16:12:10 +0200 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000343045058a6bf46c" Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 03 Jun 2019 14:12:30 -0000 --000000000000343045058a6bf46c Content-Type: text/plain; charset="UTF-8" On Mon, Jun 3, 2019 at 3:59 PM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > Our real goal needs to be mandatory sender authentication. Any secure > email gateway must go through these steps: > Our goal is defined in our charter: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ > > 1. Source Analysis: Filter message from unwanted sources > 2. Sender Authentication: Filter messages that are attempting > impersonation > 3. Content Analysis: Filter messages with unwanted content > > 1 and 3 are out of scope for this group's work. For 2, DMARC, and tweaks to SPF and DKIM to support DMARC, and this group's focus. Right now, we're working on a standards track version of DMARC. To your notes about sender authentication needing to become mandatory, do you have any recommendations on items that make this difficult for senders that should be addressed as part of the DMARCbis process? We had a call for these items that closed on 5/24, but welcome other feedback. Seth --000000000000343045058a6bf46c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2019 at 3:59 PM Douglas E.= Foster <fosterd@bayvie= wphysicians.com> wrote:
Our real goal needs to be mandato= ry sender authentication.=C2=A0 =C2=A0 Any secure email gateway must go thr= ough these steps:

Our goal is = defined in our charter:=C2=A0https://datatracker.ietf.org/doc/charter-ietf-dmarc/=
=C2=A0
  1. Source Analysis:=C2=A0 Filter message from unwanted sources
  2. Sender Authentication:=C2=A0 Filter messages that are attempting imper= sonation
  3. Content Analysis:=C2=A0 Filter messages with unwanted content

1 and 3 are out of scope= for this group's work. For 2, DMARC, and tweaks to SPF and DKIM to sup= port DMARC, and this group's focus. Right now, we're working on a s= tandards track version of DMARC.

To your notes abo= ut sender authentication needing to become mandatory, do you have any recom= mendations on items that make this difficult for senders that should be add= ressed as part of the DMARCbis process? We had a call for these items that = closed on 5/24, but welcome other feedback.

Seth
--000000000000343045058a6bf46c-- From nobody Mon Jun 3 07:30:00 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364C4120226 for ; Mon, 3 Jun 2019 07:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 qAJITAhhYoCw for ; Mon, 3 Jun 2019 07:29:56 -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 66B31120252 for ; Mon, 3 Jun 2019 07:29:56 -0700 (PDT) X-ASG-Debug-ID: 1559572195-11fa3116c82bc2c0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id aNqRqUtCiHA8yqCG (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 03 Jun 2019 10:29:55 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:to:subject; bh=JCdcZgcO6F2R3bVXDn6EjxBBG5tW9MobwwhvoE4OYNA=; b=GKR4RldgO+ua0sjfvOO975LbwqI3c/LEWLmiDgbZstXC5gS8lzFeeXtn7XIVyORMz hTYhs3B4MQh/8lMj8YjZHbJtH4SSkJZrPR+n70An2hlXrc5jMcjT2la11o/u4kL8d 7A+izuEfCshH25prixzkKYnY4yLO5sMhswpuh/+Eo= SavedFromEmail: fosterd@bayviewphysicians.com Date: Mon, 03 Jun 2019 10:29:44 -0400 Importance: normal X-ASG-Orig-Subj: Re: [dmarc-ietf] Mandatory Sender Authentication To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_672018228493450" From: "Douglas E. Foster" X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1559572195 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: 4576 X-Barracuda-BRTS-Status: 1 Message-Id: <20190603142956.66B31120252@ietfa.amsl.com> Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 03 Jun 2019 14:29:58 -0000 ----_com.samsung.android.email_672018228493450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Ci0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiAiRG91Z2xhcyBFLiBGb3N0 ZXIiIDxmb3N0ZXJkQGJheXZpZXdwaHlzaWNpYW5zLmNvbT4gRGF0ZTogNi8zLzE5ICA5OjU5IEFN ICAoR01ULTA1OjAwKSBUbzogZG1hcmNAaWV0Zi5vcmcgU3ViamVjdDogW2RtYXJjLWlldGZdIE1h bmRhdG9yeSBTZW5kZXIgQXV0aGVudGljYXRpb24gT3VyIHJlYWwgZ29hbCBuZWVkcyB0byBiZSBt YW5kYXRvcnkgc2VuZGVyIGF1dGhlbnRpY2F0aW9uLsKgIMKgIEFueSBzZWN1cmUgZW1haWwgZ2F0 ZXdheSBtdXN0IGdvIHRocm91Z2ggdGhlc2Ugc3RlcHM6CgoKCVNvdXJjZSBBbmFseXNpczrCoCBG aWx0ZXIgbWVzc2FnZSBmcm9tIHVud2FudGVkIHNvdXJjZXMKCVNlbmRlciBBdXRoZW50aWNhdGlv bjrCoCBGaWx0ZXIgbWVzc2FnZXMgdGhhdCBhcmUgYXR0ZW1wdGluZyBpbXBlcnNvbmF0aW9uCglD b250ZW50IEFuYWx5c2lzOsKgIEZpbHRlciBtZXNzYWdlcyB3aXRoIHVud2FudGVkIGNvbnRlbnQK CgpDb250ZW50IGZpbHRlcmluZyBhbHdheXMgcmVxdWlyZXMgZXhjZXB0aW9ucywgYW5kIHRob3Nl IGV4Y2VwdGlvbnMgYXJlIGdyYW50ZWQgYmFzZWQgb24gdGhlIHNlbmRlci7CoCDCoFN1Y2ggZXhj ZXB0aW9ucyBhcmUgb25seSBzYWZlIGFuZCBhcHByb3ByaWF0ZSBpZiB0aGUgc2VuZGVyIGlzIHZl cmlmaWFibGUuwqAgwqAgSWYgdGhlIGV4Y2VwdGlvbiBpcyBhcHBsaWVkIHRvIGFuIHVudmVyaWZp ZWQgc2VuZGVyLCBpdCBpcyBwb3NzaWJsZSBmb3IgYSBzcGFtbWluZyBpbXBlcnNvbmF0b3LCoHRv IGdhaW4gdGhlIGVsZXZhdGVkIHRydXN0IGFuZCByZWR1Y2VkIGZpbHRlcmluZyB3aGljaCB3YXMg b25seSBpbnRlbmRlZCBmb3IgdGhlIHRydXN0ZWQgc2VuZGVyLgoKwqAKClNvIFNlbmRlciBBdXRo ZW50aWNhdGlvbiBuZWVkcyB0byBiZWNvbWUgbWFuZGF0b3J5OgoKCglTZW5kZXJzIE1VU1TCoGlt cGxlbWVudCBTUEYgb3LCoERLSU0swqAgYW5kIFNIT1VMRCBpbXBsZW1lbnQgYm90aC7CoCBBbHRo b3VnaCB0aGUgTVggbGlzdCBiZWNvbWVzIGEgZGVmYXVsdCBTUEYgbGlzdCBmb3IgdGhvc2Ugd2hv IGRvIG5vdCBwdWJsaWlzaCBhIHBvbGljeS4KCU1UQXMgTVVTVCBlbnN1cmUgdGhhdCBES0lNIHNp Z25hdHVyZXMgcmVtYWluIHZlcmlmaWFibGUuwqAgSWYgdGhleSBhcmUgdW53aWxsaW5nIG9yIHVp bmFibGUgdG8gZG8gc28sIHRoZXkgc2hvdWxkIHJlamVjdCB0aGUgbWVzc2FnZSB3aXRowqBhIFBl cm1FcnJvci4KCUZvcndhcmRlcnMgTVVTVMKgZWl0aGVyIGZvcndhcmQgd2l0aCBicmVha2luZyBE S0lNIHNpZ25hdHVyZXMsIHJld3JpdGUgbWVzc2FnZXMgdW5kZXIgdGhlaXIgb3duIGlkZW50aXR5 LCByZWZ1c2UgdGhlIG1lc3NhZ2UsIG9yIGRpc2NhcmQgdGhlIG1lc3NhZ2UgYXMgc3BhbS4KCUlF VEYgTVVTVCBwcm92aWRlIGEgd2F5IGZvciBpbnRlcm1lZGlhdGUgc3lzdGVtcyAoYm90aCBzcGFt IGZpbHRlcnMgYW5kIGxpc3QgZm93YXJkZXJzKSB0byBpbnNlcnQgY29udGVudCB1bmRlciB0aGVp ciBvd24gc2lnbmF0dXJlLCB3aXRob3V0IGJyZWFraW5nIG9yaWdpbmFsIHNpZ25hdHVyZXMuwqAg wqAgVGhpcyB3aWxsIGhhdmUgaW1wbGljYXRpb25zIGZvciBNVUFzLi4KCgpTdXJlIGl0IHdpbGwg YmUgaGFyZCwgYnV0IGhhcyB0aGlzIG5vdCBiZWVuIHdoYXQgeW91IGhhdmUgYmVlbiB0cnlpbmcg dG8gYWNoaWV2ZcKgZm9yIDE1IHllYXJzP8KgIFNQRiBhbmQgREtJTSBwcm92aWRlZCB0aGUgZW5h YmxpbmcgdGVjaG5vbG9neSwgYnV0IHRoZXkgd2VyZSBkZXBsb3llZCBhcyBzZW5kZXIgb3B0aW9u cy4KCsKgCgpEb3VnIEZvc3RlcgoKwqAKCsKgCgrCoAoKwqAKCsKgCg== ----_com.samsung.android.email_672018228493450 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0 eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAt LT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206 ICJEb3VnbGFzIEUuIEZvc3RlciIgJmx0O2Zvc3RlcmRAYmF5dmlld3BoeXNpY2lhbnMuY29tJmd0 OyA8L2Rpdj48ZGl2PkRhdGU6IDYvMy8xOSAgOTo1OSBBTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRp dj5UbzogZG1hcmNAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBbZG1hcmMtaWV0Zl0gTWFu ZGF0b3J5IFNlbmRlciBBdXRoZW50aWNhdGlvbiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIFNhbnMtU2VyaWY7IGZv bnQtc2l6ZTogMTJweCI+PGRpdj5PdXIgcmVhbCBnb2FsIG5lZWRzIHRvIGJlIG1hbmRhdG9yeSBz ZW5kZXIgYXV0aGVudGljYXRpb24uJm5ic3A7ICZuYnNwOyBBbnkgc2VjdXJlIGVtYWlsIGdhdGV3 YXkgbXVzdCBnbyB0aHJvdWdoIHRoZXNlIHN0ZXBzOjwvZGl2PgoKPG9sPgoJPGxpPlNvdXJjZSBB bmFseXNpczombmJzcDsgRmlsdGVyIG1lc3NhZ2UgZnJvbSB1bndhbnRlZCBzb3VyY2VzPC9saT4K CTxsaT5TZW5kZXIgQXV0aGVudGljYXRpb246Jm5ic3A7IEZpbHRlciBtZXNzYWdlcyB0aGF0IGFy ZSBhdHRlbXB0aW5nIGltcGVyc29uYXRpb248L2xpPgoJPGxpPkNvbnRlbnQgQW5hbHlzaXM6Jm5i c3A7IEZpbHRlciBtZXNzYWdlcyB3aXRoIHVud2FudGVkIGNvbnRlbnQ8L2xpPgo8L29sPgoKPGRp dj5Db250ZW50IGZpbHRlcmluZyBhbHdheXMgcmVxdWlyZXMgZXhjZXB0aW9ucywgYW5kIHRob3Nl IGV4Y2VwdGlvbnMgYXJlIGdyYW50ZWQgYmFzZWQgb24gdGhlIHNlbmRlci4mbmJzcDsgJm5ic3A7 U3VjaCBleGNlcHRpb25zIGFyZSBvbmx5IHNhZmUgYW5kIGFwcHJvcHJpYXRlIGlmIHRoZSBzZW5k ZXIgaXMgdmVyaWZpYWJsZS4mbmJzcDsgJm5ic3A7IElmIHRoZSBleGNlcHRpb24gaXMgYXBwbGll ZCB0byBhbiB1bnZlcmlmaWVkIHNlbmRlciwgaXQgaXMgcG9zc2libGUgZm9yIGEgc3BhbW1pbmcg aW1wZXJzb25hdG9yJm5ic3A7dG8gZ2FpbiB0aGUgZWxldmF0ZWQgdHJ1c3QgYW5kIHJlZHVjZWQg ZmlsdGVyaW5nIHdoaWNoIHdhcyBvbmx5IGludGVuZGVkIGZvciB0aGUgdHJ1c3RlZCBzZW5kZXIu PC9kaXY+Cgo8ZGl2PiZuYnNwOzwvZGl2PgoKPGRpdj5TbyBTZW5kZXIgQXV0aGVudGljYXRpb24g bmVlZHMgdG8gYmVjb21lIG1hbmRhdG9yeTo8L2Rpdj4KCjx1bD4KCTxsaT5TZW5kZXJzIE1VU1Qm bmJzcDtpbXBsZW1lbnQgU1BGIG9yJm5ic3A7REtJTSwmbmJzcDsgYW5kIFNIT1VMRCBpbXBsZW1l bnQgYm90aC4mbmJzcDsgQWx0aG91Z2ggdGhlIE1YIGxpc3QgYmVjb21lcyBhIGRlZmF1bHQgU1BG IGxpc3QgZm9yIHRob3NlIHdobyBkbyBub3QgcHVibGlpc2ggYSBwb2xpY3kuPC9saT4KCTxsaT5N VEFzIE1VU1QgZW5zdXJlIHRoYXQgREtJTSBzaWduYXR1cmVzIHJlbWFpbiB2ZXJpZmlhYmxlLiZu YnNwOyBJZiB0aGV5IGFyZSB1bndpbGxpbmcgb3IgdWluYWJsZSB0byBkbyBzbywgdGhleSBzaG91 bGQgcmVqZWN0IHRoZSBtZXNzYWdlIHdpdGgmbmJzcDthIFBlcm1FcnJvci48L2xpPgoJPGxpPkZv cndhcmRlcnMgTVVTVCZuYnNwO2VpdGhlciBmb3J3YXJkIHdpdGggYnJlYWtpbmcgREtJTSBzaWdu YXR1cmVzLCByZXdyaXRlIG1lc3NhZ2VzIHVuZGVyIHRoZWlyIG93biBpZGVudGl0eSwgcmVmdXNl IHRoZSBtZXNzYWdlLCBvciBkaXNjYXJkIHRoZSBtZXNzYWdlIGFzIHNwYW0uPC9saT4KCTxsaT5J RVRGIE1VU1QgcHJvdmlkZSBhIHdheSBmb3IgaW50ZXJtZWRpYXRlIHN5c3RlbXMgKGJvdGggc3Bh bSBmaWx0ZXJzIGFuZCBsaXN0IGZvd2FyZGVycykgdG8gaW5zZXJ0IGNvbnRlbnQgdW5kZXIgdGhl aXIgb3duIHNpZ25hdHVyZSwgd2l0aG91dCBicmVha2luZyBvcmlnaW5hbCBzaWduYXR1cmVzLiZu YnNwOyAmbmJzcDsgVGhpcyB3aWxsIGhhdmUgaW1wbGljYXRpb25zIGZvciBNVUFzLi48L2xpPgo8 L3VsPgoKPGRpdj5TdXJlIGl0IHdpbGwgYmUgaGFyZCwgYnV0IGhhcyB0aGlzIG5vdCBiZWVuIHdo YXQgeW91IGhhdmUgYmVlbiB0cnlpbmcgdG8gYWNoaWV2ZSZuYnNwO2ZvciAxNSB5ZWFycz8mbmJz cDsgU1BGIGFuZCBES0lNIHByb3ZpZGVkIHRoZSBlbmFibGluZyB0ZWNobm9sb2d5LCBidXQgdGhl eSB3ZXJlIGRlcGxveWVkIGFzIHNlbmRlciBvcHRpb25zLjwvZGl2PgoKPGRpdj4mbmJzcDs8L2Rp dj4KCjxkaXY+RG91ZyBGb3N0ZXI8L2Rpdj4KCjxkaXY+Jm5ic3A7PC9kaXY+Cgo8ZGl2PiZuYnNw OzwvZGl2PgoKPGRpdj4mbmJzcDs8L2Rpdj4KCjxkaXY+Jm5ic3A7PC9kaXY+Cgo8ZGl2IHN0eWxl PSItd2Via2l0LXRvdWNoLWNhbGxvdXQ6IG5vbmU7IC13ZWJraXQtdXNlci1zZWxlY3Q6IG5vbmU7 IC1raHRtbC11c2VyLXNlbGVjdDogbm9uZTstbW96LXVzZXItc2VsZWN0OiBub25lOy1tcy11c2Vy LXNlbGVjdDogbm9uZTstby11c2VyLXNlbGVjdDogbm9uZTt1c2VyLXNlbGVjdDogbm9uZTsiPiZu YnNwOzwvZGl2Pjwvc3Bhbj4KPC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_672018228493450-- From nobody Mon Jun 3 07:44:36 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DF0120274 for ; Mon, 3 Jun 2019 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 2DheatpF1mic for ; Mon, 3 Jun 2019 07:44:29 -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 17182120281 for ; Mon, 3 Jun 2019 07:44:09 -0700 (PDT) Received: (qmail 35965 invoked from network); 3 Jun 2019 14:44:07 -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=8c77.5cf53237.k1906; i=johnl-iecc.com@submit.iecc.com; bh=XXdro6smIeHfw/sYbSE+fA+7KNLY9I8xC1ncvieGXh8=; b=bU8Kdvpd3hgjfxlcGunH7fa4tpzb1e+Cug0BIGhvNnGViDDa3iAougazmTM3uUTRPrEYesFdQ2tZ66NLFgWHQl8ojAYnzMYJkwsvAHLNV8Pm9K1SofGCZ9vSe7A7TrDi7fljncu958QQHd8P+OhPGWbrCDlm3pAHboXNaXMou6mrbKJX2jPPTQtuEVuoJSfB64GWVCqjhNVX1z6RxDPtR3848tf53QZ0j2oYQR4wDwtlOAv79IseKg2NevVDlMUj 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.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Jun 2019 14:44:07 -0000 Date: 3 Jun 2019 16:44:05 +0200 Message-ID: From: "John R. Levine" To: "Douglas E. Foster" Cc: dmarc@ietf.org In-Reply-To: <20190603142956.66B31120252@ietfa.amsl.com> References: <20190603142956.66B31120252@ietfa.amsl.com> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 03 Jun 2019 14:44:35 -0000 > Our real goal needs to be mandatory sender authentication. No, that's a well known FUSSP. R's, John From nobody Mon Jun 3 13:04:26 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9A12087D for ; Mon, 3 Jun 2019 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Fd9JuUdP; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=b4kuIKTQ 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 wlMg9g1oN2SX for ; Mon, 3 Jun 2019 13:04:16 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id D0BD412088D for ; Mon, 3 Jun 2019 13:04:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4695; t=1559592251; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=YNHXzocfVEayZ1T81vbILjhPW08=; b=Fd9JuUdPv5B0r5/cKGnHpT91RFXEab1XXEtCMhNka6YPAMgoQIEC2fjPXzaCCL 5wqM2VmQNM9wgQGtRwvkW6ERRCqqvLthhSo2jYKhWnkIrJV6w3H+X+h6LRscu9tJ Y3DLA3V34mwluoNtHf8naJNL3CZrgS0JnghspO26DVypE= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Mon, 03 Jun 2019 16:04:11 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 384699137.94763.3200; Mon, 03 Jun 2019 16:04:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4695; t=1559592070; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=b2RkFzA NwbYA/mtllQQ9hO/p18ZRsOvdjU2aEGbPqRc=; b=b4kuIKTQLv/Yuu8cMpOBoj3 VWbJ0j2B37BZoTrnN0NhSTtgqQPjhQmsVOsdy+TDEG94ZfNgLTXNxCGiDfKQ0zS+ K0Fnbv0fhNadvxQF30gDbvPXAD/Zrw8rSZ2wQZotSGc0vovbX+4S/5wE6X44+1ym wFdL+YTBZouVbd/FJY8A= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Mon, 03 Jun 2019 16:01:10 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1956926113.9.290564; Mon, 03 Jun 2019 16:01:10 -0400 Message-ID: <5CF57D3A.1090406@isdg.net> Date: Mon, 03 Jun 2019 16:04:10 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> In-Reply-To: <20190603142956.66B31120252@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 03 Jun 2019 20:04:24 -0000 On 6/3/2019 10:29 AM, Douglas E. Foster wrote: > So Sender Authentication needs to become mandatory: > > * Senders MUST implement SPF or DKIM, and SHOULD implement both. > Although the MX list becomes a default SPF list for those who do > not publiish a policy. > * MTAs MUST ensure that DKIM signatures remain verifiable. If they > are unwilling or uinable to do so, they should reject the message > with a PermError. > * Forwarders MUST either forward with breaking DKIM signatures, > rewrite messages under their own identity, refuse the message, or > discard the message as spam. > * IETF MUST provide a way for intermediate systems (both spam > filters and list fowarders) to insert content under their own > signature, without breaking original signatures. This will have > implications for MUAs.. > > Sure it will be hard, but has this not been what you have been trying > to achieve for 15 years? SPF and DKIM provided the enabling > technology, but they were deployed as sender options. Hi Douglas, It's ideal, but not the SMTP realities. - In certain areas, some things are already "mandatory" depending on the business, for example, a Bank may be required by their auditor to use SPF Hard Fail -ALL policy in the same way a bank must be PCI compliant via the web which basically means SSL, session management and other security-related requirements. - You can't enforce anything beyond legacy RFC821/5321 transactions under Port 25 SMTP operations. You can only raise the email bar with NON-PORT 25 operations like when using the Message Submission protocol (RFC6409) which is port 587. For example, the Extended SMTP (ESMTP) AUTH protocol is not required under Port 25. It is optional to implement and optional to use by the client. Under Port 587, ESMTP AUTH is a requirement among other things the receiver can enforce which are not required under port 25 operations. - We can not have a mandate for DKIM POLICY because there is no official IETF standard here and even if there was, it would not be enforcible under Port 25. That's not the same as a domain having a restrictive policy, it fails and the receiver honors and rejects the mail. The Receiver can not enforce the sender to have a DKIM or any sort of policy above and beyond legacy SMTP port 25 operations. It can not reject a message on the basis the sender does not have SPF or DKIM or DMARC. - Keep in mind, SPF Hard Failures are generally good enough and can be mutually exclusive of a restrictive DKIM Policy. For example, I just did some emailing with a bank which uses SPF -ALL (Hard Fail) but has no DKIM signature nor DMARC policy. For exclusive high value domains, an SPF -ALL is often good enough. Even if it had a DKIM/DMARC p=reject policy, how will that change a -ALL failure? Why would a bank override a SPF -ALL failure with with DMARC (or ARC) and raise the fussiness of the transaction? I am sure there is possible a scenario where a SPF -ALL defined IP is doing something different with the PAYLOAD and could fail a DKIM signature. But the reason you may see a domain with SPF -ALL and not DKIM is because it is good enough. - Without port 25 operations, we would no longer be able to receive unsolicited messages from anyone, good or bad which is the blessing and the curse of standard SMTP port 25 operations. The general rule of thumb for SMTP has been that for unsolicited mail from "unknown" addresses, authenticated and/or authorization is not required when targeting a local recipient or locally hosted domain. But for relaying mail (receiving a message to be routed, relayed to a remote target), some level of authentication is required and in the history of SMTP, that has been: - Having some form of an "Allow IP Relay" database/table. Your network provider saves the connection IP in a table allowing for relay. But as the roaming user problem began where the client's IP can change, an early method called POP B4 SMTP was common. - POP b4 SMTP worked on the basis a MUA will generally pop first before sending email and this allowed a small temporary "Allow IP" window for the SMTP client to send mail. So the POP3 client connected to a host, the IP was saved while any new mail was picked up. If the MUA had mail to send out, the client IP would be known by the SMTP receiver and allow the client to relay mail. This was a god-send for tech support before ESMTP AUTH came along and becamewide spread: - ESMTP AUTH allows a way to login with ID and Password from anywhere. No IP required. Since ESMTP AUTH is an extension for PORT 25, it is not requirement. -- HLS From nobody Mon Jun 3 23:50:19 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8D81200CD for ; Mon, 3 Jun 2019 23:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net 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 BJFsVFVbUWFj for ; Mon, 3 Jun 2019 23:50:16 -0700 (PDT) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 0A005120059 for ; Mon, 3 Jun 2019 23:50:15 -0700 (PDT) Received: by mail-yw1-xc33.google.com with SMTP id s5so8567457ywd.9 for ; Mon, 03 Jun 2019 23:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=s7u7hd3qn6RnVlfY2Rr9dC8+UEcTA3hDrSMKiGSkukI=; b=HaQIcl+z5NpB7OLlgS3OgS3CI2AkQQJyVGiwz80c0yGLZgoEvEYzzKow926fPLtMNN AMBf76csxim9aDSM0xwBLTxJ1JtP3AqYAVRliji3/mh5+3ijJwbBq/GFLdSNjQ+dsbzo 7ydeFXok2PvXxcnkk9QnDnqLa47kBo1XVlS/k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=s7u7hd3qn6RnVlfY2Rr9dC8+UEcTA3hDrSMKiGSkukI=; b=ZZlCFpMhpta6NJua3dG+S99ZnltiAlmoMizIIqv+8nQaWXLT2uGugFeEIUgqh7cctz nBSR4xkXMIVTKsZk1Zx5FMavmQSZBMJiFBhO2u198q651tICoyn8VH+XijYYSjj9+DHv Yvh/IRW8C3uHW3BZtaR+CLll8FsnWIx6NvZrsDpedNPD8kLp282YhqIuKpA4VB4TVDF8 pUht01+7st7zpgJvlAjKLA6tpsrqYRVcAw6b9JqVG9LsMpXALNwCaDQ8bLPGj6+4D/lb eTKVRHWJPlUKOA0C4kxTqEcVWT7ukHnnavGqiSsM1UC2RnQYS87espzP7SvQUdlBf2sr cf7w== X-Gm-Message-State: APjAAAVwvlXMKzau9NKHt9IO8tu0Wsp4I/18kKiGJR86jO1FPubK5Jvp /tWllyJLk/17X0I9eWbBl44yaQuKcwQ= X-Google-Smtp-Source: APXvYqyTxc5qLrclozTSOw0ipqmgTRG40k/ucwTMOXEOcuZXe5hl/BRgv4eT5Qdw5NPAZRvXQp2jJQ== X-Received: by 2002:a81:3d86:: with SMTP id k128mr15598668ywa.466.1559631014822; Mon, 03 Jun 2019 23:50:14 -0700 (PDT) Received: from [192.168.0.14] ([68.235.242.215]) by smtp.gmail.com with ESMTPSA id k64sm55813ywf.37.2019.06.03.23.50.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 23:50:13 -0700 (PDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_C3ED2918-AD14-4591-AED1-3A6A5AA882FE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 4 Jun 2019 02:50:12 -0400 References: <20190523225213.C214620147B780@ary.qy> To: IETF DMARC WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy 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, 04 Jun 2019 06:50:18 -0000 --Apple-Mail=_C3ED2918-AD14-4591-AED1-3A6A5AA882FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 30, 2019, at 2:13 PM, Murray S. Kucherawy = wrote: >=20 > On Wed, May 29, 2019 at 10:13 AM John R Levine > wrote: > As far as I can tell your proposal to break the document in two has=20 > gotten no support at all. Can we stop now? >=20 > What's on topic for the group and what isn't is the purview of the = co-chairs and the charter. Let's please not stifle discussions before = they die on their own absent chair action to the contrary. FWIW, one reason why the document lists the XML today is to emphasize = the importance of this reporting piece. A few people are fond of saying: email receivers can do whatever the = heck they want with their email. Part of DMARC's "social contract" = between domain owners and email receivers is to allow email receivers to = implement DMARC's policy model "safely" by means of telling domain = owners via reporting what the email receivers are doing. In other words, the model works as email receivers can push support = burden back to domain owners *if* aggregate reporting is in place. As = simple as it might sound, keeping the XML parts in the 'core' document = is (was?) supposed to make it very clear what parts should be considered = required. -=3D Tim --Apple-Mail=_C3ED2918-AD14-4591-AED1-3A6A5AA882FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = May 30, 2019, at 2:13 PM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Wed, May 29, 2019 = at 10:13 AM John R Levine <johnl@taugh.com> wrote:
As far as I can tell your proposal to = break the document in two has
gotten no support at all.  Can we stop now?

What's on topic for the group and what isn't is the purview = of the co-chairs and the charter.  Let's please not stifle = discussions before they die on their own absent chair action to the = contrary.

FWIW, one reason why the document lists the XML = today is to emphasize the importance of this reporting = piece.

A few people are fond of = saying: email receivers can do whatever the heck they want with their = email. Part of DMARC's "social contract" between domain owners and email = receivers is to allow email receivers to implement DMARC's policy model = "safely" by means of telling domain owners via reporting what the email = receivers are doing.

In other words, = the model works as email receivers can push support burden back to = domain owners *if* aggregate reporting is in place. As simple as it = might sound, keeping the XML parts in the 'core' document is (was?) = supposed to make it very clear what parts should be considered = required.

-=3D Tim

= --Apple-Mail=_C3ED2918-AD14-4591-AED1-3A6A5AA882FE-- From nobody Tue Jun 4 00:11:06 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F0120131 for ; Tue, 4 Jun 2019 00:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net 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 Hkhb7PwF6v_d for ; Tue, 4 Jun 2019 00:11:03 -0700 (PDT) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (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 2E9411200A4 for ; Tue, 4 Jun 2019 00:11:03 -0700 (PDT) Received: by mail-yw1-xc30.google.com with SMTP id u134so1612011ywf.6 for ; Tue, 04 Jun 2019 00:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UANBEDa2o0FTj1tokMF80jOpVz16nj3mfZr4CeTP5RQ=; b=NvE88g/qYE5+FYo1mAjxogj+Hg0SDYSA7gbuaD6JjQuW5EgnJzyrS/GsUiwKqlu9mg ENpq8LtCvwBF/6bngbGlIXobp1DKadMGEBHZjuOzHSbjd2MyauWtMYmYwYGEj3x/TRyQ S3CqzXl349S9+QCz+R2CvUGC4bBt2VuV4a2dI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UANBEDa2o0FTj1tokMF80jOpVz16nj3mfZr4CeTP5RQ=; b=F5dknKu25xDsIm3NnEnOQYgaJWNeE/2JpA/+pPKa4QL5kkJCv4ILpoGIZs3bA64Z8i c3T/wjnZ/epPYOQDjFM4BKUVVOfOug7ryoeYatzt1DTjY54sP7kJ2oZuyBQf27xEH5aj XiIs6B4uYRuX6xbRp+oSUwV9teq6rYMCDS02Va6eNjw6mFPEP5hO82DjwvI4xiwHwHsh pQz9XHUvV8P9u0WeAyn58pbCVV6x7dhJeHT/OwVnH1PDler8C4CQeetSHC33NUPSskma IP1Y3AwaL+iOZ4D7i34jKcA5NfRjHQpouA9I9n3EFBB7a243Hn54PjxuR6cWfUqQ+u36 RfxA== X-Gm-Message-State: APjAAAV2uXChy99DnmTbtlmw2VQE/2UjLJfWjizuqCCtVnsO9cRtL1Fa IiCxDmK8mywZW8yM1LOhpNW7nRxJw5I= X-Google-Smtp-Source: APXvYqwoLEH5qSa2VJKEFj6E5iUDJmsnEns8QuewT7rOFG15+F1Oqxv+HpEwFyMRx8ZyuDG7BrOI7g== X-Received: by 2002:a81:3ac7:: with SMTP id h190mr7732984ywa.362.1559632262157; Tue, 04 Jun 2019 00:11:02 -0700 (PDT) Received: from [192.168.0.14] ([68.235.242.215]) by smtp.gmail.com with ESMTPSA id z141sm4358404ywa.108.2019.06.04.00.11.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 00:11:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tim Draegen In-Reply-To: <20190527192255.2DEAA2014AD91A@ary.qy> Date: Tue, 4 Jun 2019 03:11:00 -0400 Cc: IETF DMARC WG Content-Transfer-Encoding: 7bit Message-Id: <3FAFCF1F-0E6E-4DC0-9DE9-78E3A4750114@eudaemon.net> References: <20190527192255.2DEAA2014AD91A@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: failure report mail loops 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, 04 Jun 2019 07:11:05 -0000 > On May 27, 2019, at 3:22 PM, John Levine wrote: > > Apropos recent discussions, we could recommend that failure reports be > rate limited per recipient both to break loops and to deter indirect > mail bombing. Hi John et al, I've added this suggestion to the tracker: https://trac.ietf.org/trac/dmarc/ticket/28 From nobody Tue Jun 4 00:21:07 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AB01200F4 for ; Tue, 4 Jun 2019 00:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net 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 Xwk0E7Wm7Cta for ; Tue, 4 Jun 2019 00:21:04 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 372371200A4 for ; Tue, 4 Jun 2019 00:21:04 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id y2so7598526ybo.3 for ; Tue, 04 Jun 2019 00:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dyN8IorBDyjWTTnxVXQWFbewEw+H6BQ4OSuJSw0CiUk=; b=JMJr9a6jrCdnjcPMoe2uilJlZW1dYuYGiguhEK6D+y+VV/6e3Nb2y33ZrAh1YbV/jh RtzxGMPoczI5+OXjsNKeRMy5ltFV2IpZZxLmr/d+bqHdIgrPXLl2SitlW0gLaFb9e17g BA1GXFpMwH8oolryw7FMRjj1NJScF8194khec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dyN8IorBDyjWTTnxVXQWFbewEw+H6BQ4OSuJSw0CiUk=; b=T1/bT1j2fnOLGcxkY2qDLruC9ewv4jmwyTsWdriXwbZYWQX8NxnwoEiqAbilYIrob5 6+CMeD9aQHJ6ohiaKKN/3G7wEfT4ymGygA21djREgKWZb2HGWw7LEQRF6hIjlnNmQ+RF FzVJYLuwvGjo+NAU2+PqkbyRN1lNhE2cHJhMC0pRRZX3khOC51WYv0kh0S0IqCK9yQaZ laAL6N2mMLDuqhnHM3kTFnVVLoju70LLUHuHP8XdnWgKse5gyk6BfEOXWX5obsec9jZ7 5pCfrvJNtwWv02mm2UAKKDbhpDPD5HuZ5lQ60ofWd29jN92/cypdhdy/o7eA2ojZtwOJ ysKA== X-Gm-Message-State: APjAAAUxZ5EY4tLOzsLEFwhZ4iVeonTv4tki12rG8IPM/uC4kJO6nSxr Q2/sco8CxkCtYwT9BziPC3Xz6g== X-Google-Smtp-Source: APXvYqza3tm+IwcMTMEZpK7OyyeLJAe+TMyUCwWh+oc9ZfxAGpp9FrDsMeI30ZzgzXv8cPFX7UNQ6w== X-Received: by 2002:a25:c7d1:: with SMTP id w200mr14998668ybe.54.1559632863243; Tue, 04 Jun 2019 00:21:03 -0700 (PDT) Received: from [192.168.0.14] ([68.235.242.215]) by smtp.gmail.com with ESMTPSA id b14sm4396433ywb.1.2019.06.04.00.21.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 00:21:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tim Draegen In-Reply-To: <20190527193203.4B74F2014AD9CA@ary.qy> Date: Tue, 4 Jun 2019 03:21:01 -0400 Cc: dmarc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <56D45AF9-3C51-46DF-B346-C317B4BAABC5@eudaemon.net> References: <20190527193203.4B74F2014AD9CA@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Reporting URIs 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, 04 Jun 2019 07:21:06 -0000 > On May 27, 2019, at 3:32 PM, John Levine wrote: >=20 > Section 6.3 says that ruf and rua tags can take any URI, but only > define the meaning of a mailto: URI. Either it should define some > other URI schemes or it should say that only mailto: URIs are valid. >=20 > Back in the olden days there was an http or https scheme that we took > out because it was ill specified, and nobody but me had tried to > implement it. If people are interested in an https PUT scheme it > would be easy enough to define one, but only if someone says they want > to use it. For large reports it could be somewhat faster than mailto > both because the report body isn't base64 encoded and the report goes > straight to the https server and doesn't get relayed as mail does. FWIW I've added this to the tracker: https://trac.ietf.org/trac/dmarc/ticket/29#ticket ..and have mentioned the http POST scheme for TLSRPT. Feel free to add = more context if you'd like. =3D- Tim From nobody Tue Jun 4 00:23:37 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF461200F4 for ; Tue, 4 Jun 2019 00:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 lEza4OoVWyse for ; Tue, 4 Jun 2019 00:23:32 -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 C2D9B1200A4 for ; Tue, 4 Jun 2019 00:23:32 -0700 (PDT) Received: from [172.16.22.211] (80-64-77-66.static.acetelecom.hu [80.64.77.66]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x547PWYP032637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2019 00:25:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559633134; bh=8J59xZ7+kttGnKiyCeRiQgo2EoscQwZu+cqqfv3mO3s=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=dn990k48WFbVPmvgMAGsJTFNEEzJsd2bud2OWz6e043EwhpYsAbdj/RT6lyl+fzmk re57v/wRlHkKKXshJuNJn1nRZgwjI3riD4um+0IS/KIpJ1x5zM6uvRfZSGSpIFLElw eEmcSQqlwYYOXYKoaa9U8tp733iw9AbdVM3+3XqQ= To: "Douglas E. Foster" , dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Message-ID: <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> Date: Tue, 4 Jun 2019 09:23:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190603142956.66B31120252@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 04 Jun 2019 07:23:36 -0000 On 6/3/2019 4:29 PM, Douglas E. Foster wrote: > > Our real goal needs to be mandatory sender authentication.    Any secure > email gateway must go through these steps: 1. By 'sender', which actor in the sequence do you mean? The term is highly ambiguous. 2. Your certitude presumes an empirical foundation, given how often good theory does not make good practice. People have been working in this space for a very long time and one might have expected the industry to have latched on such a simple requirement were it that clear it was /the/ essential requirement. Please document the basis for your certitude. 3. What made you think that 'sender' authentication is not already happening at a sufficient level? What is the basis for believing it isn't already being used by filtering agents well enough? 4. Consider the limitations to 'sender' authentication. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 4 00:47:23 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94971200CE for ; Tue, 4 Jun 2019 00:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net 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 09fpyqyUyFVP for ; Tue, 4 Jun 2019 00:47:19 -0700 (PDT) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 972BD12006A for ; Tue, 4 Jun 2019 00:47:19 -0700 (PDT) Received: by mail-yw1-xc35.google.com with SMTP id t2so646310ywe.10 for ; Tue, 04 Jun 2019 00:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=rNG/WF/8CqoBffuGkfDp1FwMZ01f6inGgvSPNoEauo8=; b=RwNZ1K7vzrrGG/PD2NNNDpHMZeVi4DTr0bbF7hdolI1AfZPLwrEB8S+f6/5m9aCRjv FPVUqHWPq9ewY2iuBe31204LnLjFn8lOzPwq8cJnalud3EYiPERflD7DtzQfZjoJgton iQTTFt/0pzLldZ0x/gnsChrPoXiNqndJkk6ck= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=rNG/WF/8CqoBffuGkfDp1FwMZ01f6inGgvSPNoEauo8=; b=LY03mx2LPo45hS1fUiuDbObzI66dzt5w3By0goio6MHaQgKZTcGeTJEznuZGIgX4YW KUDqALnefEc6dcQFL7xnubQV6/lE9SPRnK5MBwPGmM8nwHtbrRE97NcCmtupwRujxRfi AR6GcXfxPiQbFkjD8UsaCFL2HwcILMrhv7hw7inMZTVZBtJIhWHxhHxrR68QTIUNlT6J JvfAuq8T6cwUfIfHmb/HljmIvw4VlN0OBIZ3ksDgBU5jPpcOujDHpIF4gfoHh0YUpyUz 33cdKWSwOFpKn32rR/Uy164zgODPhLZHV341BDMLw9UpqPjVurd1t1HPXh61Lpey5ll2 HvNw== X-Gm-Message-State: APjAAAXUkcTyMsc1TGqIjfOtQCl0gswrr11WLCB86Huey+uviF6phB67 J7niiBK1y5Gs/lAwve33OWWjsPhwQ7M= X-Google-Smtp-Source: APXvYqxLxVtuJcgXjOuJo/cAuvMUWu8qY1RTVHRgj+LE2dCDOyeS6DjWT2/5qEaid4/LdJJ4BQyTDw== X-Received: by 2002:a81:5e8b:: with SMTP id s133mr16477224ywb.149.1559634438504; Tue, 04 Jun 2019 00:47:18 -0700 (PDT) Received: from [192.168.0.14] ([68.235.242.215]) by smtp.gmail.com with ESMTPSA id l6sm1203767ywi.86.2019.06.04.00.47.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 00:47:17 -0700 (PDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_AFA1C2DF-D2B9-49A0-B1FD-C4A13CEF1783" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 4 Jun 2019 03:47:16 -0400 References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> To: IETF DMARC WG In-Reply-To: Message-Id: <6B17221E-25B4-4031-B758-7EA6B92FBA6E@eudaemon.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 07:47:22 -0000 --Apple-Mail=_AFA1C2DF-D2B9-49A0-B1FD-C4A13CEF1783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 1, 2019, at 4:13 AM, Murray S. Kucherawy = wrote: >=20 > On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov = > wrote: > Shall I submit an erratum to RFC7489? >=20 > I would, yes. And this should certainly be recorded as something we = need to fix for standards track DMARC, whether by chasing down RFC7489 = errata or via a dedicated issue in this WG's tracker. I did not see this item submitted as errata, so I put it into the = tracker: https://trac.ietf.org/trac/dmarc/ticket/30 I'd like to float the idea that this scenario might be something = operators address when they're generating reports (perhaps mentioned in = DMARC Usage Guide?).=20 That said, the NOTIFY=3DNEVER idea makes a lot of sense to me, but I = have to admit I'm not exactly sure how easy it is for operators to set = this. If its not super obvious and available everywhere for free, I have = to assume this means it'll be partially deployed forever, which puts us = back at square one. Sending with an empty RFC5321.MAILFROM sort of turns DMARC reports into = a form of DSN. Implications unknown!= --Apple-Mail=_AFA1C2DF-D2B9-49A0-B1FD-C4A13CEF1783 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Jun 1, 2019, at 4:13 AM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov = <Dilyan.Palauzov@aegee.org> wrote:
Shall I = submit an erratum to RFC7489?

I would, yes.  And = this should certainly be recorded as something we need to fix for = standards track DMARC, whether by chasing down RFC7489 errata or via a = dedicated issue in this WG's = tracker.

I did not see this item submitted as errata, so I put it into = the tracker:

  https://trac.ietf.org/trac/dmarc/ticket/30

I'd like to float the = idea that this scenario might be something operators address when = they're generating reports (perhaps mentioned in DMARC Usage = Guide?). 

That said, the NOTIFY=3DNEVER idea makes a lot of sense = to me, but I have to admit I'm not exactly sure how easy it is for = operators to set this. If its not super obvious and available everywhere = for free, I have to assume this means it'll be partially deployed = forever, which puts us back at square one.

Sending with an empty RFC5321.MAILFROM = sort of turns DMARC reports into a form of DSN. Implications = unknown!
= --Apple-Mail=_AFA1C2DF-D2B9-49A0-B1FD-C4A13CEF1783-- From nobody Tue Jun 4 02:28:10 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F044912006D for ; Tue, 4 Jun 2019 02:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqciXqVOUuym for ; Tue, 4 Jun 2019 02:28:07 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D7E120046 for ; Tue, 4 Jun 2019 02:28:06 -0700 (PDT) Authentication-Results: mail.aegee.org/x549S2JK024990; auth=pass (PLAIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1559640484; i=dkim+MSA-tls@aegee.org; r=y; bh=YofTRApD02LwRmrRiT3CH3e+SUOBFObZnU7eCbSqLW8=; h=Date:Subject:To:From; b=PjgLcCBb5aHyew/xDrk7PICMoyYckTRLDgRXGJAy/BqfIBkW2N1ni1NuE7ILudC0i L8Ng59xs7OsDvBMwfTM9rmgaB/N4KNc/DhpkHNHhJfxqwt8JukQDcTSUvKQ/XmaGjM /+9zsQ0NPB79d/6g8WqZV0FuhlD5Q2/b5z9eHX1nhh/6gRM00uNv/anSM1ID5pcHdk oh8wBcPcZbdgl5IHdz9UJG2TWN+Rz/AU/GKTXBDL4ADn/QUklovc2DQd0HoVeBaNUP up+9GMlZAXsckgMJiezNPVroUmXO1Wpk6EgkVuu0v44PngmLIqlR+RNqHboTy1ZXC3 Xl4VebjfZ4K/aMQAzl11cleO3tdc0o+ymQdGz+ikif9BW15u0FyhixLbz9xTRqiJRO SaMEaJEs6YYzTX4Lgn7jZu1l/fOUjsife9OtJIyozo+PCFUad4neMPK2HYnwNAZ8cm Ft9F7YWKwB6xRxQql92n1cdKYEdfchQBXSsN54qkkp/gzZPZbe5CJlQW16tGrwSB+v wage8SAImVNFsdPgRvRss9VLETBStlPjXqcCChvlJjjWQxdK1EFCVjcq/Wkp+eBnBj cUr2LxU0JKdUJ+BMTNoKKbTxoOVpJJXpNYF4KN9OYHj0PIXBfOMAD/dxA69LQ7Wzj8 0i+gVLF7/ioUrjGsDn+zvWvM= Authentication-Results: mail.aegee.org/x549S2JK024990; dkim=none Received: from [10.40.49.174] (x527179ae.dyn.telefonica.de [82.113.121.174]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x549S2JK024990 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 4 Jun 2019 09:28:04 GMT Date: Tue, 04 Jun 2019 12:27:52 +0300 User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----1D0BA60H2U0ON6J3CRLHU1ONJHCC6A" Content-Transfer-Encoding: 7bit To: IETF DMARC WG From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Message-ID: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 09:28:09 -0000 ------1D0BA60H2U0ON6J3CRLHU1ONJHCC6A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, the reporting per RFC 6651 can also cause endless email loops: A DKIM failure report is sent, on which a bounce is generated and the boun= ce contains DKIM-Signature: r=3Dy with invalid signature=2E So a new DKIM f= ailure report is generated=2E The signature does not have to be invalid, ha= ving broken validator also messes the situation=2E Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD ------1D0BA60H2U0ON6J3CRLHU1ONJHCC6A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,

the reporting per RFC 6651 can also cause endless email loops= :

A DKIM failure report is sent, on which a bounce is generated and = the bounce contains DKIM-Signature: r=3Dy with invalid signature=2E So a ne= w DKIM failure report is generated=2E The signature does not have to be inv= alid, having broken validator also messes the situation=2E

Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD ------1D0BA60H2U0ON6J3CRLHU1ONJHCC6A-- From nobody Tue Jun 4 02:46:01 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6031200CD for ; Tue, 4 Jun 2019 02:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net 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 jxmbA9vut48J for ; Tue, 4 Jun 2019 02:45:58 -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 BDE11120046 for ; Tue, 4 Jun 2019 02:45:58 -0700 (PDT) Received: from [172.16.22.211] (80-64-77-66.static.acetelecom.hu [80.64.77.66]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x549hrbH019729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2019 02:43:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559641437; bh=GnuQRA6JKAYwZJiKZ1DB97ccQk+NY8tICKR6Anr0mK0=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=KR8vNB1niiwOxCprmmwNJzM5n1OzsR64XjuLI/sLaqhHcZn5RudKjHE/saCzPMATI kdSt1aJPDfpfa2FhZOP9bM21R8ckHuJ0K68JXmLpKnquQF442L+p3jJYBIbEzG0JBn SInNauAuu3EbD4JiVNCIVy8S8yCTGCid9jcqb5SQ= To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , IETF DMARC WG References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> Reply-To: dcrocker@bbiw.net From: Dave Crocker Message-ID: Date: Tue, 4 Jun 2019 11:41:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 09:46:00 -0000 On 6/4/2019 11:27 AM, Дилян Палаузов wrote: > A DKIM failure report is sent, on which a bounce is generated The rule for mail-handling notification messages has been that they do not contain a return address, in order to avoid looping. Shouldn't that apply to DMARC reports, too? If not, why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 4 04:01:48 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966291200D6 for ; Tue, 4 Jun 2019 04:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3tsf2XJobKr for ; Tue, 4 Jun 2019 04:01:45 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71A5120018 for ; Tue, 4 Jun 2019 04:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1559646102; bh=rhBaYwjLF8sE1XUhQMqcxd8g55hNYEE3kBBoxgVY8Z0=; l=627; h=To:From:Date; b=B1GN6+Fc+Yov34Ux9IDUZhI/Dh9Nc6sCi1bSUpgzTQStKW3zUT7g7Z2b4WVaSu6EB H9wG8Ik0NI0CN/j7twJFhvkAt34EbTJOf2stV9wtY7dA2aEFzuMmeb3PCnHljH6pCm iWhpDX9y+O0Q/d57ABSGrJ2G+KgeFP+vucQG0XLrnl9rblLoEub8wcc0UCZCA Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 04 Jun 2019 13:01:42 +0200 id 00000000005DC03D.000000005CF64F96.000014AB To: IETF DMARC WG From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Tue, 4 Jun 2019 13:01:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 11:01:46 -0000 Hi all, Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF's reject-on-fail. The score attributed to the sender by a trusted DNSWL is also useful after DATA, thence the need to store that value for downstream filters. However, as an authentication method, a DNSWL TXT response can provide a domain name, which is possibly aligned with From:. In that sense, this method might be of interest for this WG. Probably not, but I felt compelled to make sure before trying independent submission. (Already tried ART.) The I-D is here: https://tools.ietf.org/html/draft-vesely-authmethod-dnswl Best Ale -- From nobody Tue Jun 4 04:48:45 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3020D120089 for ; Tue, 4 Jun 2019 04:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 M5HPSeU7u8VO for ; Tue, 4 Jun 2019 04:48:41 -0700 (PDT) Received: from smtp36.i.mail.ru (smtp36.i.mail.ru [94.100.177.96]) (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 7ED4C12004A for ; Tue, 4 Jun 2019 04:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=LRYCa4Bic78ER9QxM36g22iK8GB7+TIC52zePzqZlj0=; b=DSgHWbqS0nwt2kYSXGoSfWSP7MengrlhMV4xMradeExeeIz0WpkptDb8+r2pdQ2Mg4Tc8/7qRVEYZz6hyo93ozcGJQt6nnlo/eRUwRWkE2oZMICalwlDCvyqAxyxq6s3HYbvadBOfu8R6TbMpG/09vkaIi91PTpWR5e4rIY+/BY=; Received: by smtp36.i.mail.ru with esmtpa (envelope-from ) id 1hY7vi-0005Ne-LE; Tue, 04 Jun 2019 14:48:38 +0300 To: dcrocker@bbiw.net, =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , IETF DMARC WG References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: Date: Tue, 4 Jun 2019 14:48:32 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: ru Authentication-Results: smtp36.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 9956FF8ABC4DA899D342E2602075DC2270618619B7F34FC6439EF68518BA20BF X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 11:48:44 -0000 Reports are not sent to Return-Path address, empty return path does not prevents report from being sent. Actually, report with empty envelope-from has higher chances to generate a reverse report, because in this case SPF is checked against HELO and, in practice, many seders do not have SPF configured for HELO name and SPF failure can trigger a report. 04.06.2019 12:41, Dave Crocker пишет: > On 6/4/2019 11:27 AM, Дилян Палаузов wrote: >> A DKIM failure report is sent, on which a bounce is generated > > The rule for mail-handling notification messages has been that they do > not contain a return address, in order to avoid looping.  Shouldn't > that apply to DMARC reports, too?  If not, why? > > d/ > -- Vladimir Dubrovin @Mail.Ru From nobody Tue Jun 4 05:12:56 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664C9120115 for ; Tue, 4 Jun 2019 05:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net 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 Wk5McY-yRUu9 for ; Tue, 4 Jun 2019 05:12:53 -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 0E65F1200FD for ; Tue, 4 Jun 2019 05:12:53 -0700 (PDT) Received: from [172.16.22.211] (80-64-77-66.static.acetelecom.hu [80.64.77.66]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x54CAgeu006616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2019 05:10:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559650247; bh=rrjPhjC+pTjNjnwLnrubM4v9rdXCGfCsKBUWABuInIc=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=DZePffJxfqUSVdKH4S86GqeUrneUOhJKYQD8Oyr9WyfPAKCHjirzUomS8PxACXJMK k+zgmACQ8GdzdNDqSOe8mC16+0RQDD3suoQ0c6A9nt57R1JRz7FLcBZfRs6GvlcS4a RZSVkVvx/9HUQE024lhnWW4Ow4vEcOfgXl7pll2o= To: Vladimir Dubrovin , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> Cc: IETF DMARC WG Reply-To: dcrocker@bbiw.net From: Dave Crocker Message-ID: <2a93577c-ee69-5edf-c347-dff46f568189@dcrocker.net> Date: Tue, 4 Jun 2019 14:08:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 12:12:54 -0000 On 6/4/2019 1:48 PM, Vladimir Dubrovin wrote: > Reports are not sent to Return-Path address, empty return path does not > prevents report from being sent. Actually, report with empty My comment was meant about the DMARC report being sent without a return (envelope from) address, the same as is already true for other email infrastructure control messages. > envelope-from has higher chances to generate a reverse report, because I don't understand how it is possible to send a report when there is no address to send it to. > in this case SPF is checked against HELO and, in practice, many seders > do not have SPF configured for HELO name and SPF failure can trigger a > report. I don't understand how the HELO domain name is relevant to this discussion, since it isn't a full email address. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 4 05:27:19 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B28120086 for ; Tue, 4 Jun 2019 05:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 JlN5_jT1s9F1 for ; Tue, 4 Jun 2019 05:27:15 -0700 (PDT) Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (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 02074120033 for ; Tue, 4 Jun 2019 05:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=eLBgzwN/66ma9JByX4+GOcxoiDPREss0XTPYxtYp774=; b=fIlkzGTDIOlesMl5qZnN7eVgPkB/+n/WpC+gGGkTquKuspN584384d6l8TMlWGElQ+nepVEaNbPLcKkV4sQXafJHZN9eta6hmwx3NHhhGZ6WASVLiJ9J6omzK4AfbL0GEUHDAx8UZUN3utZF08T2W+9x32D7CImGUBmTDLslgNA=; Received: by smtp38.i.mail.ru with esmtpa (envelope-from ) id 1hY8X2-0002W6-Hw; Tue, 04 Jun 2019 15:27:12 +0300 To: dcrocker@bbiw.net, =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: IETF DMARC WG References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> <2a93577c-ee69-5edf-c347-dff46f568189@dcrocker.net> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: <90ae3a6d-f6bf-f079-2844-bb30245b3bbd@corp.mail.ru> Date: Tue, 4 Jun 2019 15:27:11 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <2a93577c-ee69-5edf-c347-dff46f568189@dcrocker.net> Content-Type: multipart/alternative; boundary="------------C19E1DDBD7452145324C5303" Content-Language: ru Authentication-Results: smtp38.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 29F8160D69F1D3A872228BA86744144440518506734E3D9CCE58903009102E3E X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 12:27:18 -0000 This is a multi-part message in MIME format. --------------C19E1DDBD7452145324C5303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 04.06.2019 15:08, Dave Crocker пишет: > On 6/4/2019 1:48 PM, Vladimir Dubrovin wrote: >> Reports are not sent to Return-Path address, empty return path does not >> prevents report from being sent. Actually, report with empty > > My comment was meant about the DMARC report being sent without a > return (envelope from) address, the same as is already true for other > email infrastructure control messages. > DMARC reports are triggered based on the domain in RFC5322.From address and are sent to DMARC reporting address from DMARC record for RFC5322.From address. If one DMARC reports triggers another DMARC reports, the second report will be sent to DMARC reporting address, not to return-path. > >> envelope-from has higher chances to generate a reverse report, because > > I don't understand how it is possible to send a report when there is > no address to send it to. Report destination address is different from return-path or the message which triggers a report, so message with empty return-path (envelope-from) can trigger a valid DMARC report and it will be delivered to DMARC reporting address. > > >> in this case SPF is checked against HELO and, in practice, many seders >> do not have SPF configured for HELO name and SPF failure can trigger a >> report. > > I don't understand how the HELO domain name is relevant to this > discussion, since it isn't a full email address. DMARC reporting can report and SPF or SPF alignment failure (RFC 7598 sections 4.2, 6.3) . According to section 2.4 of RFC 7208 (SPF) 2.4 . The "MAIL FROM" Identity ... [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321] ). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the local-part "postmaster" and the "HELO" identity (which might or might not have been checked separately before). > > d/ > > > -- Vladimir Dubrovin @Mail.Ru --------------C19E1DDBD7452145324C5303 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
04.06.2019 15:08, Dave Crocker пишет:
On 6/4/2019 1:48 PM, Vladimir Dubrovin wrote:
Reports are not sent to Return-Path address, empty return path does not
prevents report from being sent. Actually, report with empty

My comment was meant about the DMARC report being sent without a return (envelope from) address, the same as is already true for other email infrastructure control messages.


DMARC reports are triggered based on the domain in RFC5322.From address and are sent to DMARC reporting address from DMARC record for RFC5322.From address. If one DMARC reports triggers another DMARC reports, the second report will be sent to DMARC reporting address, not to return-path.



envelope-from has higher chances to generate a reverse report, because

I don't understand how it is possible to send a report when there is no address to send it to.


Report destination address is different from return-path or the message which triggers a report, so message with empty return-path (envelope-from) can trigger a valid DMARC report and it will be delivered to DMARC reporting address.




in this case SPF is checked against HELO and, in practice, many seders
do not have SPF configured for HELO name and SPF failure can trigger a
report.

I don't understand how the HELO domain name is relevant to this discussion, since it isn't a full email address.


DMARC reporting can report and SPF or SPF alignment failure (RFC 7598 sections 4.2, 6.3) . According to section 2.4 of RFC 7208 (SPF)


2.4.  The "MAIL FROM" Identity
...

   [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
   [RFC5321]).  In this case, there is no explicit sender mailbox, and
   such a message can be assumed to be a notification message from the
   mail system itself.  When the reverse-path is null, this document
   defines the "MAIL FROM" identity to be the mailbox composed of the
   local-part "postmaster" and the "HELO" identity (which might or might
   not have been checked separately before).



d/ 




-- 
Vladimir Dubrovin
@Mail.Ru
--------------C19E1DDBD7452145324C5303-- From nobody Tue Jun 4 06:19:55 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E345120033 for ; Tue, 4 Jun 2019 06:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOKKNWAa7RzP for ; Tue, 4 Jun 2019 06:19:51 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9006812001E for ; Tue, 4 Jun 2019 06:19:50 -0700 (PDT) Authentication-Results: mail.aegee.org/x54DJiqA007997; auth=pass (PLAIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1559654386; i=dkim+MSA-tls@aegee.org; r=y; bh=xp3XvFYvCyjPa/2cmJPt2xpgvjOg1XgUOU/d467CRVc=; h=Date:In-Reply-To:References:Subject:To:CC:From; b=niph0hiWCB9JBXKFjx4xAaA8GcZRDVSMOvpDjpALCBLrPdfdEBwCysxoMpa/wX8qB xnX5OmxgtzDxMSO8gTw+oRULncNfkcWjRdzgpBAk4vh9Uh7+NXpWNKhWGwuqIkWhiv gG9JJAN4FgiLLp9bhTOJczLmhl0jzi3uWU+oQrHMkJ4/vj0fbhXOam9ralKEZqj4fR 54NBzwYKINOIc5vDrGQVf6hseJdWh2kdmx8hUeUpAjbAERlxgk3ZNJ/2Ah+rt0w7Cm jzkXfKmzhfCKW9f6tnp/iHXnsnsofAmwjcU9nm+sXeNujgDGaQIvTmHxFhaiApMSIF E8RidBt2Rur/XcUP8A716lBnCwWD8KgRRB4ggJOLPgDUKk9FlAwYFoSZ/D0U16fixY f7gcZiX+of0a/KwebplOaGUNdv/qgxT1dbjsd655izOA+ZgjVLhcac0chO4SneJm99 +04ZzK+37EN/kOGlytA5TxjCSE5FdiV1ypljER4Gc2k2c/z3xMQPmHbtNgEdmvJFnJ KGKFKlPBGNeisEKsxGqMY5/oaN3ISuKCQ7fqjliVPH+qPCRrec0TMkm9R33QsRczPf PA/qprNy1lwydN38l3vGlQ8C6NwQXEUEi9+ET0EqW+sj7XsSJ06iHTPKNLPAv9pNns VAMTx/d+rlQJiMeIOONUuL5M= Authentication-Results: mail.aegee.org/x54DJiqA007997; dkim=none Received: from [10.130.18.157] (x2e72229d.dyn.telefonica.de [46.114.34.157] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x54DJiqA007997 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Jun 2019 13:19:45 GMT Date: Tue, 04 Jun 2019 16:19:26 +0300 User-Agent: K-9 Mail for Android In-Reply-To: References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----Z0XIYT9ZV62MX895PPEVKA5GC9OL4Z" Content-Transfer-Encoding: 7bit To: Vladimir Dubrovin CC: IETF DMARC WG From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Message-ID: X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 13:19:53 -0000 ------Z0XIYT9ZV62MX895PPEVKA5GC9OL4Z Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Validimir, the point is that answers can be sent to the (DKIM) report and receiving t= he answers can trigger sending a new report to the address published in DNS= =2E Empty return path prevents sending an answer to the report=2E What to do if a site sends a report that does not validate DMARC/DKIM, the= n a new (reverse) report by the other host is sent and this report again do= es not validate DMARC/DKIM, so it triggers a new report? This is a concern = of improperly configured site pairs=2E The target for the recommendation to= use MAIL FROM:<>/NOTIFY=3DNEVER are properly configured sites, that deal w= ith improperly configured sites=2E Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD On June 4, 2019 2:48:32 PM GMT+03:00, Vladimir Dubrovin wrote: > >Reports are not sent to Return-Path address, empty return path does not >prevents report from being sent=2E Actually, report with empty >envelope-from has higher chances to generate a reverse report, because >in this case SPF is checked against HELO and, in practice, many seders >do not have SPF configured for HELO name and SPF failure can trigger a >report=2E > >04=2E06=2E2019 12:41, Dave Crocker =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On 6/4/2019 11:27 AM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB= =D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: >>> A DKIM failure report is sent, on which a bounce is generated >> >> The rule for mail-handling notification messages has been that they >do >> not contain a return address, in order to avoid looping=2E=C2=A0 Should= n't >> that apply to DMARC reports, too?=C2=A0 If not, why? >> >> d/ >> > >--=20 >Vladimir Dubrovin >@Mail=2ERu ------Z0XIYT9ZV62MX895PPEVKA5GC9OL4Z Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Validimir,

the point is that answers = can be sent to the (DKIM) report and receiving the answers can trigger send= ing a new report to the address published in DNS=2E

Empty return pat= h prevents sending an answer to the report=2E

What to do if a site s= ends a report that does not validate DMARC/DKIM, then a new (reverse) repor= t by the other host is sent and this report again does not validate DMARC/D= KIM, so it triggers a new report? This is a concern of improperly configure= d site pairs=2E The target for the recommendation to use MAIL FROM:<>= /NOTIFY=3DNEVER are properly configured sites, that deal with improperly co= nfigured sites=2E

Regards
=D0=94=D0=B8=D0=BB=D1=8F=D0=BD

<= div class=3D"gmail_quote">On June 4, 2019 2:48:32 PM GMT+03:00, Vladimir Du= brovin <dubrovin@corp=2Email=2Eru> wrote:

Reports are not sent to Return-Path address, emp=
ty return path does not
prevents report from being sent=2E Actually, rep=
ort with empty
envelope-from has higher chances to generate a reverse re=
port, because
in this case SPF is checked against HELO and, in practice,=
 many seders
do not have SPF configured for HELO name and SPF failure ca=
n trigger a
report=2E

04=2E06=2E2019 12:41, Dave Crocker =D0=BF=
=D0=B8=D1=88=D0=B5=D1=82:
On 6/4/2019 11:27 AM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=
=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote:
A DKIM failure report is sent, on which a bounce is generate=
d

 The rule for mail-handling notification messages has=
 been that they do
 not contain a return address, in order to avoid loop=
ing=2E  Shouldn't
 that apply to DMARC reports, too?  If not, =
why?

 d/

------Z0XIYT9ZV62MX895PPEVKA5GC9OL4Z-- From nobody Tue Jun 4 06:46:03 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2412004E for ; Tue, 4 Jun 2019 06:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net 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 qQyX4mB0xRBH for ; Tue, 4 Jun 2019 06:46:00 -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 337A6120033 for ; Tue, 4 Jun 2019 06:46:00 -0700 (PDT) Received: from [172.16.22.211] (80-64-77-66.static.acetelecom.hu [80.64.77.66]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x54DdpX4016948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jun 2019 06:39:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559655600; bh=wSClbNImV++Au08YbW9kcra6HcRzoeAy9WAU0iHX+Gg=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=ZtDRvcoZLrMGGNKs947aOpsCbtA3EKNGpPgso0lmFCc5LrRCFSx7xJOJ/aYmgbwuc Ss3CWd676Qxr/r1u3eoimwkn0yVmgCY0xYR7zmefbnWGJvZrQuFvM99IXvJNfY7oVm BqsCtEuEPWERJPzn/mKIk/q0Wuz9AJhSZlyuUqNQ= To: Vladimir Dubrovin , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: IETF DMARC WG References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> <2a93577c-ee69-5edf-c347-dff46f568189@dcrocker.net> <90ae3a6d-f6bf-f079-2844-bb30245b3bbd@corp.mail.ru> From: Dave Crocker Reply-To: dcrocker@bbiw.net Message-ID: <29174612-a051-8066-9dde-2afaf181ca0e@dcrocker.net> Date: Tue, 4 Jun 2019 15:37:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <90ae3a6d-f6bf-f079-2844-bb30245b3bbd@corp.mail.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 13:46:02 -0000 >> My comment was meant about the DMARC report being sent without a >> return (envelope from) address, the same as is already true for other >> email infrastructure control messages. > > DMARC reports are triggered based on the domain in RFC5322.From address > and are sent to DMARC reporting address from DMARC record for > RFC5322.From address. If one DMARC reports triggers another DMARC > reports, the second report will be sent to DMARC reporting address, not > to return-path. That's an issue only if the report is sent from an address that has a DMARC record. Which might be a good reason NOT to send from such an address. The high-level point I'm trying to make is that control messages -- such as DMARC reports -- need to be handled in a fashion that works automatically and at scale. Since looping is a well-known problem for such messages, they need to be generated and handled in a way that prevents the problem. >>> in this case SPF is checked against HELO and, in practice, many seders >>> do not have SPF configured for HELO name and SPF failure can trigger a >>> report. >> >> I don't understand how the HELO domain name is relevant to this >> discussion, since it isn't a full email address. > > > DMARC reporting can report and SPF or SPF alignment failure (RFC 7598 > sections 4.2, 6.3) . According to section 2.4 of RFC 7208 (SPF) Yes, but how is that relevant to the problem of DMARC report looping? It's merely one of the causes of a DMARC failure, but sources of failure isn't the issue with respect to report looping. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 4 07:30:11 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E988B1200C4 for ; Tue, 4 Jun 2019 07:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 jCeYT3NaPlNZ for ; Tue, 4 Jun 2019 07:30:06 -0700 (PDT) Received: from smtp17.mail.ru (smtp17.mail.ru [94.100.176.154]) (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 4DAB512007C for ; Tue, 4 Jun 2019 07:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=YVPHNu0gskIdPs6PRFT+Q+oVkDIeoN0hYb38myo6ntU=; b=fhtwG2a+ODjBt/L0iO/J+FRrANoMnSFF1rKV8Ye7HJFcAvg/Yhva1DLoztG6R647o7G8YPkfTzzWBrKCoqBjU4QlPdSP62yPK6wH3vU1wgERHb3PKL6aZWlPXxURPTR0mqfcivMgnwZZWST8llxgX+siCCGdvzL+TOsVvZqDMlQ=; Received: by smtp17.mail.ru with esmtpa (envelope-from ) id 1hYARk-0002iu-IT; Tue, 04 Jun 2019 17:29:52 +0300 To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: IETF DMARC WG References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: <227c8736-7726-4d9b-ff34-f329cd116ebf@corp.mail.ru> Date: Tue, 4 Jun 2019 17:29:51 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CFD7E979517A239C918F2C47" Content-Language: ru Authentication-Results: smtp17.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 1FE9CBA2155F3F2BCEE4A2186C42CB99D7FACD6A0A04E20507A6B130B0B3B9F7 X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 14:30:10 -0000 This is a multi-part message in MIME format. --------------CFD7E979517A239C918F2C47 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I see your point, but actually empty return-path doesn't guarantee the DKIM/DMARC report to not receive the answer either, because e.g. out-of-office autoreplies usually ignore return-path and send response to RFC5322.Reply-To/RFC5322.From. It's quite common case human-readable mailbox is set as a DMARC reporting address. I believe, valid recommendations here is to follow RFC 3834 for both sender and recipient, that is, to add Auto-Submitted: auto-generated header (Precedence: bulk may also be used, though not standardized) Recommendation to use empty envelope-from / return-path is doubtful, because this recommendation is usually applied to mail transport-level application and DMARC reporting does not belong to transport level. In practice, this recommendation will increase loop probability for DMARC reports due to quite common SPF misconfiguration. 04.06.2019 16:19, Дилян Палаузов пишет: > Hello Validimir, > > the point is that answers can be sent to the (DKIM) report and > receiving the answers can trigger sending a new report to the address > published in DNS. > > Empty return path prevents sending an answer to the report. > > What to do if a site sends a report that does not validate DMARC/DKIM, > then a new (reverse) report by the other host is sent and this report > again does not validate DMARC/DKIM, so it triggers a new report? This > is a concern of improperly configured site pairs. The target for the > recommendation to use MAIL FROM:<>/NOTIFY=NEVER are properly > configured sites, that deal with improperly configured sites. > > Regards > Дилян > > On June 4, 2019 2:48:32 PM GMT+03:00, Vladimir Dubrovin > wrote: > > Reports are not sent to Return-Path address, empty return path does not > prevents report from being sent. Actually, report with empty > envelope-from has higher chances to generate a reverse report, because > in this case SPF is checked against HELO and, in practice, many seders > do not have SPF configured for HELO name and SPF failure can trigger a > report. > > 04.06.2019 12:41, Dave Crocker пишет: > > On 6/4/2019 11:27 AM, Дилян Палаузов wrote: > > A DKIM failure report is sent, on which a bounce is generated > > The rule for mail-handling notification messages has been that > they do not contain a return address, in order to avoid > looping.  Shouldn't that apply to DMARC reports, too?  If not, > why? d/ > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------CFD7E979517A239C918F2C47 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I see your point, but actually empty return-path doesn't guarantee the DKIM/DMARC report to not receive the answer either, because e.g. out-of-office autoreplies usually ignore return-path and send response to RFC5322.Reply-To/RFC5322.From. It's quite common case human-readable mailbox is set as a DMARC reporting address.

I believe, valid recommendations here is to follow RFC 3834 for both sender and recipient, that is, to add

Auto-Submitted: auto-generated

header (Precedence: bulk may also be used, though not standardized)

Recommendation to use empty envelope-from / return-path is doubtful, because this recommendation is usually applied to mail transport-level application and DMARC reporting does not belong to transport level. In practice, this recommendation will increase loop probability for DMARC reports due to quite common SPF misconfiguration.

04.06.2019 16:19, Дилян Палаузов пишет:
Hello Validimir,

the point is that answers can be sent to the (DKIM) report and receiving the answers can trigger sending a new report to the address published in DNS.

Empty return path prevents sending an answer to the report.

What to do if a site sends a report that does not validate DMARC/DKIM, then a new (reverse) report by the other host is sent and this report again does not validate DMARC/DKIM, so it triggers a new report? This is a concern of improperly configured site pairs. The target for the recommendation to use MAIL FROM:<>/NOTIFY=NEVER are properly configured sites, that deal with improperly configured sites.

Regards
Дилян

On June 4, 2019 2:48:32 PM GMT+03:00, Vladimir Dubrovin <dubrovin@corp.mail.ru> wrote: 
Reports are not sent to Return-Path address, empty return path does not
prevents report from being sent. Actually, report with empty
envelope-from has higher chances to generate a reverse report, because
in this case SPF is checked against HELO and, in practice, many seders
do not have SPF configured for HELO name and SPF failure can trigger a
report.

04.06.2019 12:41, Dave Crocker пишет:

On 6/4/2019 11:27 AM, Дилян Палаузов wrote:

A DKIM failure report is sent, on which a bounce is generated


 The rule for mail-handling notification messages has been that they do
 not contain a return address, in order to avoid looping.  Shouldn't
 that apply to DMARC reports, too?  If not, why?

 d/



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



-- 
Vladimir Dubrovin
@Mail.Ru
--------------CFD7E979517A239C918F2C47-- From nobody Tue Jun 4 08:01:47 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31714120077 for ; Tue, 4 Jun 2019 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTvgNYUpc_D0 for ; Tue, 4 Jun 2019 08:01:38 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB0512002F for ; Tue, 4 Jun 2019 08:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1559660496; bh=BhgeG8eFHhliWe15BejEWc/sISu7Si0c8qF+ML5nA9Y=; l=2085; h=To:References:From:Date:In-Reply-To; b=BlXuvWPWYVhCIFeIZH0FxhYqbts3H/224+2lgwWeuTicIOlsB9nO8M/4GJpslLOoa 1gqBFvAOkY7bfPEjnlIZoRgzJLWpVlshjMTtDe1d/1KqovmHIi44Zd0/o8FKBQ/XSk Tot6uQcF254HXqWhDl46VUU1dEC2EdrLZ0jEqpg85OxJLPVjkqnU71aqgZO9P Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 04 Jun 2019 17:01:36 +0200 id 00000000005DC077.000000005CF687D0.00002E6E To: Tim Draegen , IETF DMARC WG References: <20190531175532.Horde.UpMFNBGKjRWB_hCZWHwSUfK@webmail.aegee.org> <6B17221E-25B4-4031-B758-7EA6B92FBA6E@eudaemon.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Tue, 4 Jun 2019 17:01:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <6B17221E-25B4-4031-B758-7EA6B92FBA6E@eudaemon.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Endless Email Loops with Aggregate Reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 15:01:40 -0000 Hi Tim, On Tue 04/Jun/2019 09:47:16 +0200 Tim Draegen wrote: >> On Jun 1, 2019, at 4:13 AM, Murray S. Kucherawy >>> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov >>> >>> Shall I submit an erratum to RFC7489? >>> >> >> I would, yes.  And this should certainly be recorded as something we need to >> fix for standards track DMARC, whether by chasing down RFC7489 errata or via >> a dedicated issue in this WG's tracker. > > I did not see this item submitted as errata, so I put it into the tracker: > >   https://trac.ietf.org/trac/dmarc/ticket/30 > > I'd like to float the idea that this scenario might be something operators > address when they're generating reports (perhaps mentioned in DMARC Usage Guide?).  That's a good idea. > That said, the NOTIFY=NEVER idea makes a lot of sense to me, but I have to > admit I'm not exactly sure how easy it is for operators to set this. If its not > super obvious and available everywhere for free, I have to assume this means > it'll be partially deployed forever, which puts us back at square one. > > Sending with an empty RFC5321.MAILFROM sort of turns DMARC reports into a form > of DSN. Implications unknown! Not quite. The ticket is wrong in mentioning bounces, because they don't trigger an aggregate report. Aggregate reports cover _any_ message that is received with a From: domain having a DMARC record and a rua address. That obviously includes any aggregate reports that is received from the relevant address. The best solution I saw is not to send aggregate reports from a domain that has a DMARC record with a rua address: http://lists.dmarc.org/pipermail/dmarc-discuss/2018-October/004164.html When I read that, I changed the From: header field of my generator, but I'm not sure I did fix anything. Once triggered, that kind of loop would last forever, with 1 every day from both sides acknowledging each other's report. I looked for such a loop and found none, perhaps because every other domain had already applied the trick? Best Ale -- From nobody Tue Jun 4 08:21:40 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ECB12015D for ; Tue, 4 Jun 2019 08:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=R9TNwm5I; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=T7EM2lZE 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 dPGKXa-fVCHi for ; Tue, 4 Jun 2019 08:21:38 -0700 (PDT) Received: from mail.winserver.com (ntbbs.santronics.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 16134120155 for ; Tue, 4 Jun 2019 08:21:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2215; t=1559661688; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=dk8O9V9bJ7igHka99+DZImLRAU8=; b=R9TNwm5ItduV9jtbyTf3GTvBgSaoUJ9cybcVL8jAUuSmKh8jsi2+EBHKUL6C7n oVJV331VyCbrS/ex1CzR0PcwuBH7exbgIJ6VcIxaHESnlfTqfwL7Xf/Of5LR6zOL PjU/POagYLR2OuXUIEXtY/In1aQH1eWjKFvcjYwFNfBhE= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Tue, 04 Jun 2019 11:21:28 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 454135182.94763.480; Tue, 04 Jun 2019 11:21:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2215; t=1559661507; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qKL5lY5 ZDg9PkotH/u3g/G5lFynxBhCunP2lgNKW9XA=; b=T7EM2lZEo9wACCD3bypH25a RUGXQhGWG22Bv9nPjafY3R2xHy5vNp6XyN4p36RIKoLtRnYdgWhyODgvUGui6kP5 hLI4PtQXr/w5X8ir3JZWQM6HY0ryUzgBABzJnbIDIe5LkUaPnSqs67lnXyOKr+1t OnACUj57nM5jYkZ+Ku18= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Tue, 04 Jun 2019 11:18:27 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2026362160.9.72100; Tue, 04 Jun 2019 11:18:26 -0400 Message-ID: <5CF68C79.6030408@isdg.net> Date: Tue, 04 Jun 2019 11:21:29 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <26D82EA6-8E39-4AED-BB9D-E2F53E7548C4@aegee.org> <227c8736-7726-4d9b-ff34-f329cd116ebf@corp.mail.ru> In-Reply-To: <227c8736-7726-4d9b-ff34-f329cd116ebf@corp.mail.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 15:21:40 -0000 On 6/4/2019 10:29 AM, Vladimir Dubrovin wrote: > > Recommendation to use empty envelope-from / return-path is doubtful, > because this recommendation is usually applied to mail transport-level > application and DMARC reporting does not belong to transport level. In > practice, this recommendation will increase loop probability for DMARC > reports due to quite common SPF misconfiguration. So with what protocol transport mechanism are DMARC reports sent? The basic design question I see here is what return path to use for a DMARC report. The considerations would be: C: MAIL FROM:<> C: MAIL FROM: The first format is known as the NULL return path. From what I see in my quick check of May and June logs, I did not see any NULL return path usage, but I do see the following style from three big ISPs: C: MAIL FROM: C: MAIL FROM: C: MAIL FROM: Two of them are using non-standard "noreply" user-id string, sub-string concept in a non-standard attempt to expose the idea the receiver (or user) should not attempt to reply/bounce the messages. Google has recognized this "noreply" tag and they made it not fail a CBV (Call Back Verification) check. Yahoo will fail a CBV check and thus its dmarc reports are not received by my commercial package by default, out of the box. I just added a local white list for this, but this points out the need to conform to a practice known to help prevent "responses" to a notification by using NULL return path address. Otherwise, in the future DMARC reporting document, it needs to specify a new "special user-id" (left hand side of address) that will tell up-to-par compliant DMARC report receivers to not reply to it. We can't presume that a general idea of using a "noreply" string or substring of a user id signifies a valid report or notification. It can be a "loop hole" for bad guy mail entry abuse when it begins to pre-empt return path validity checking. All this is another reason why we should consider splitting DMARC PS work into two documents. Policy and Reporting. -- HLS From nobody Tue Jun 4 15:37:55 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCF12003F for ; Tue, 4 Jun 2019 15:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net 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 ZeFLeJ5n0QGF for ; Tue, 4 Jun 2019 15:37:50 -0700 (PDT) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 EC78E120242 for ; Tue, 4 Jun 2019 15:37:49 -0700 (PDT) Received: by mail-yw1-xc2a.google.com with SMTP id b143so965150ywb.7 for ; Tue, 04 Jun 2019 15:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=WcfXbBet/e6LOYIMkT1ytNkEx82NK3WwkInIaSjSGQ0=; b=O3tlB108/OiDh7qsKt4PTGA2i9OmKr3hNW0wLBeHMReSDzofynE21nnqjhSdAWUy70 hilZTqeEJcFWmOHDGza0lW6ECWZartZh0Mo6kdgQOobd2CEBlw7GVfUcu080RFfFqMkz uKQ2ZrnVw0mC5XLFP03Tl0eA81AU/U5M2adKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=WcfXbBet/e6LOYIMkT1ytNkEx82NK3WwkInIaSjSGQ0=; b=NptgOoEmcN9vjUY4G0LKEr5hniPkY1cKW5BTYW3Mu8+h/TEh90SxuV4KV5xo5dOlsW VhAFXiRMfAvq21vPI+ZyPb/xZodDpzVcCKUv5UJ6rcaTQcvqKUkMziLqHTSzygKmz70N JHSRXx+x9rgBQcUNH/grfpmqS+YFwtL2XE6MoYtrxoDdZJdbH4uIBBMc9r1JsTWCEyxA roncy6s0zr0MBvoDx//uqlTF1MlUJr6OIzrNkoyHRLs+njX0pKqdUpRAQ7DiKetf8V8D UQG7JoCzp/B2Sd1xUJyDsn9+graUsxbzRH+w3CNtF2YfcHQtcCYU6hJ20pzCTzsBnVjw EZcQ== X-Gm-Message-State: APjAAAVRuYaKBWctV3pJxsRYiofpUBL7aTnoSpYer4sAk4HCngRNNRhM O4tOLC08HqdfhUkTN+xAtQHTIEyriuk= X-Google-Smtp-Source: APXvYqzoG6W3ObdlkDQnwzCfh9M2iNVFJ7CRpDUIFqou2X1hbolnAk34bNa2DpkSwnuQumHqoysiVw== X-Received: by 2002:a81:3250:: with SMTP id y77mr7765148ywy.437.1559687868625; Tue, 04 Jun 2019 15:37:48 -0700 (PDT) Received: from [192.168.203.118] ([68.235.232.199]) by smtp.gmail.com with ESMTPSA id b132sm5046163ywb.87.2019.06.04.15.37.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 15:37:48 -0700 (PDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 4 Jun 2019 18:37:47 -0400 References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580> To: IETF DMARC WG In-Reply-To: <2350589.KE7Alnpban@l5580> Message-Id: <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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: Tue, 04 Jun 2019 22:37:53 -0000 > On May 27, 2019, at 6:59 PM, Scott Kitterman = wrote: >=20 > On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org wrote: >> 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. >>=20 >> Title : DMARC (Domain-based Message Authentication, >> Reporting, and Conformance) Extension For PSDs (Public Suffix = Domains) >> Author : Scott Kitterman >> Filename : draft-ietf-dmarc-psd-04.txt >> Pages : 11 >> Date : 2019-05-27 >=20 > There isn't much to this update. It corrects one typo and reverts the = RUF=20 > MUST NOT as discussed on the list. As far as I'm aware there are no = other=20 > pending issues in the WG with the draft. Hi Scott, I've reviewed the doc and have made some comments. Feel free = to dispose of them as you will. I had a hard time with the introduction. "sets of domains within a = single organization" and "lower level policy" left me not knowing what I = was reading. I'm unhappy just complaining, so I took a stab at this = admittedly difficult section. The original: DMARC [RFC7489] provides a mechanism for publishing organizational policy information to email receivers. DMARC [RFC7489] allows policy to be specified for both individual domains and sets of domains within a single organization. For domains above the organizational level in the DNS tree, policy can only be published for the exact domain. There is no method available to such domains to express lower level policy or receive feedback reporting for sets of domains. This prevents policy application to non-existent domains and identification of domain abuse in email, which can be important for brand and consumer protection. My stab: DMARC [RFC7489] provides a mechanism for publishing organizational policy information to email receivers. DMARC [RFC7489] allows policy to be specified for both individual domains and for organizational domains and their sub-domains within a single organization. For TLDs and domains that exist = between TLDs and organization level domains, policy can only be published for = the exact domain. No method is available for such domains to express policy or receive feedback reporting for sub-domains. This missing method allows for the abuse of non-existent = organizational-level domains and prevents identification of domain abuse in email. The example section doesn't read like the rest of the draft and was hard = for me to read through. Original: This would provide policy and feedback for mail sent from @gov.example, but not @tax.gov.example and there is no way to publish an organizational level policy that would do so. While, in theory, receivers could reject mail from non-existent domains, not all receivers do so. Non-existence of the sending domain can be a factor in a mail delivery decision, but is not generally treated as definitive on its own. Again my stab: This DMARC record provides policy and a reporting destination for = mail sent from @gov.example. However, due to DMARC's current method of discovering = and applying policy at the organizational domain level, the non-existent = organizational domain of @tax.gov.example does not and cannot fall under a DMARC policy. I don't have too much more, I just got just caught up in the initial = read. This paragraph contains a construct that was confusing to me: This memo provides a simple extension to DMARC [RFC7489] to allow operators of Public Suffix Domains (PSDs) to express policy for groups of subdomains, extends the DMARC [RFC7489] policy query functionality to detect and process such a policy, describes receiver feedback for such policies, and provides controls to mitigate potential privacy considerations associated with this extension. ^^^ why "groups of subdomains" and not just "subdomains"? One step = further, why not "express policy at the level of the PSD that covers all = organizational domains that do not explicitly publish DMARC records"? OK, two more things: 2.3. Longest PSD Organizational Domain (DMARC [RFC7489] Section 3.2) with one label removed. ^^^ "one left-most label removed"? Last thing: Security considerations might call out DNS cache poisoning = as a way to get reports for a PSD. Applies to vanilla DMARC too, but the = scope and potential breadth of information with PSD-DMARC is really = interesting. I imagine an attack that gets .COM listed into the PSD = Registry for a specific report generator.. combined with cache poisoning = and the poor report generator would probably explode at best. From nobody Wed Jun 5 13:06:26 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E531200FD for ; Wed, 5 Jun 2019 13:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=CJsXnjkk; dkim=pass (1536-bit key) header.d=taugh.com header.b=I4wLM3SW 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 ZaOPKngPKaIj for ; Wed, 5 Jun 2019 13:06:23 -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 26D971200B5 for ; Wed, 5 Jun 2019 13:06:22 -0700 (PDT) Received: (qmail 94336 invoked from network); 5 Jun 2019 20:06:21 -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=1707e.5cf820bd.k1906; i=johnl-iecc.com@submit.iecc.com; bh=MlugDaPZ+YZkpSBmWCD4spX+x/GHDearRd0daymRlVA=; b=CJsXnjkkjezlK/3orNDuLGj4UTfQxcc2NERjPnwBd20MzbOTMCtecbGqhxcgZMu2i0hk55p7PKPe46UCYdG1l34ATXfpAK6FbJBakNHu96FGIX1xL6noCTH1cNgbgaF8UmZ720NmMgyRNWR1OIo+s9bkL2Sr8xgstMzttKmQIcAF5fuVQ/oq7hBk0dqT/Rdk/jZoM6hRl0FhttgB40uZNWsSPMyO+xxz7bSCTetNejy9oqNTMlfpMOJGhnGsTYO+ 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=1707e.5cf820bd.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=MlugDaPZ+YZkpSBmWCD4spX+x/GHDearRd0daymRlVA=; b=I4wLM3SWXnSn2VXDqsIApY89n9aLRl5zAntyDPlIReE5iayG4KutItg5AqdPMvy/t0od2z7L4wttxUflaRiWJxgtE+f7BAZ/al+Llw70uLj+SXt1CxAJ6efF4Z9tiPaydeaklqtzlXO2PxldKi+htF3aWmdbEajGGUjUtMlUgn1xC8qyZ+sPNwK+AZMX5+pSy4gW2Boi6f4B4ibNE6jq0U88dNFvtbjWzdIUFSIM9N6r/45BrqT/Pz6xDwPLERWY Received: from ary.local ([109.74.56.122]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 05 Jun 2019 20:06:20 -0000 Received: by ary.local (Postfix, from userid 501) id 2ED512014FE9B7; Wed, 5 Jun 2019 22:06:18 +0200 (CEST) Date: 5 Jun 2019 22:06:18 +0200 Message-Id: <20190605200619.2ED512014FE9B7@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <29174612-a051-8066-9dde-2afaf181ca0e@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 20:06:25 -0000 In article <29174612-a051-8066-9dde-2afaf181ca0e@dcrocker.net> you write: >The high-level point I'm trying to make is that control messages -- such >as DMARC reports -- need to be handled in a fashion that works >automatically and at scale. Since looping is a well-known problem for >such messages, they need to be generated and handled in a way that >prevents the problem. Right. you can give all the advice you want about sending stuff in ways that's intended to prevent responses, but since some people will always ignore your good advice, and any single party only controls one leg of the loop, the only unlateral way to limit the damage is rate limiting. It's fine to tell people to use null bounce addresses and from: addresses that don't ask for dmarc reports, but you need to rate limit anyway. From nobody Thu Jun 6 00:03:32 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593C120191 for ; Thu, 6 Jun 2019 00:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 iUrrT15QSctv for ; Thu, 6 Jun 2019 00:03:27 -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 9AFDA120115 for ; Thu, 6 Jun 2019 00:03:27 -0700 (PDT) Received: from [172.16.22.211] (80-64-77-66.static.acetelecom.hu [80.64.77.66]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x5675XNM026211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2019 00:05:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559804735; bh=6af3KgbDQI8XROE3CYDDFhblwUxAJTs1oyeCVSpo4KQ=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=Vdfe1fKVU2nu1poyn2h3PKmoh4glIJzIrkNkbU5M5dRRYBjwCLaccEd2I6HHqcatJ +NbVr72hRecDSJDwfQJj9RyMDFgk4hB+ALbXJAnnVI0WSj0pEGA8RE1u+xfbCX6RR9 lJlZhpzVO0owwJYte4dYpbqdHNe/lvs/v2a6zbls= To: John Levine , dmarc@ietf.org References: <20190605200619.2ED512014FE9B7@ary.local> From: Dave Crocker Reply-To: dcrocker@bbiw.net Message-ID: <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> Date: Thu, 6 Jun 2019 09:03:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190605200619.2ED512014FE9B7@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 07:03:30 -0000 On 6/5/2019 10:06 PM, John Levine wrote: > In article <29174612-a051-8066-9dde-2afaf181ca0e@dcrocker.net> you write: >> The high-level point I'm trying to make is that control messages -- such >> as DMARC reports -- need to be handled in a fashion that works >> automatically and at scale. Since looping is a well-known problem for >> such messages, they need to be generated and handled in a way that >> prevents the problem. > > Right. you can give all the advice you want about sending stuff in > ways that's intended to prevent responses, but since some people will > always ignore your good advice, and any single party only controls one > leg of the loop, the only unlateral way to limit the damage is rate > limiti Taking your note's plain language, you appear to be of the rather peculiar view that specifying standards doesn't matter, since people won't follow them. Looping is a classic problem. It has classic solutions. Getting the details of one specified for this case is, of course, different from getting people to adopt it, but the start is with specifying it. Having additional, ad hoc mechanisms for dealing with non-compliance is quite a separate matter. > It's fine to tell people to use null bounce addresses and from: > addresses that don't ask for dmarc reports, but you need to rate limit > anyway. I looked at the rest of this thread, to see where this point had already been made, since your note seems to have a tone implying it's an established point, but I couldn't find it. So again, ad hoc mechanisms might also be useful, but they are separate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jun 6 01:08:52 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F1512009E for ; Thu, 6 Jun 2019 01:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=b4avU3P+; dkim=pass (1536-bit key) header.d=taugh.com header.b=bLsySfqB 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 LHHwy551o8R4 for ; Thu, 6 Jun 2019 01:08:49 -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 D44DD12001A for ; Thu, 6 Jun 2019 01:08:48 -0700 (PDT) Received: (qmail 70445 invoked from network); 6 Jun 2019 08:08:47 -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=1132b.5cf8ca0f.k1906; i=johnl-iecc.com@submit.iecc.com; bh=A3JxVQcaJjqp3gvgnA+qmSygpfENBd/gBEFxgkI7OKE=; b=b4avU3P+wSRNrAG5YKnuZPS579ABAF0T4EsosJFsxaIRBfMsHAlZRa20JUNUmtbdY8GNm4RQ2vrYeuE3yWDlPZn9Jecr977GuMN0enGkXLW86uSHjB4EJqPkc0iO4CVXMBxRYHRUXc+WMEfqxcYh+F4seJznLmPnWDpQn84o6UuhB0hBnwnRjcVE+OgoWvOmJvfG2knEtIxZ0yL6xyCOFNNY/KcdhPheyHcg+5vrqkYBVTX9FgyzhbytrDLerH0a 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=1132b.5cf8ca0f.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=A3JxVQcaJjqp3gvgnA+qmSygpfENBd/gBEFxgkI7OKE=; b=bLsySfqBYh+CakrKLW+9lGyNUU9gO8Ed8O6keW/cxeSDShVWwh+mMjpzDaMdoCLy9QCckzR4QuWGyTybLr24cVe8arJ87m22gN9bmfr9BrhumxQWE0ESU6gH9nxl6Bf4BEDRxOqjgfo9/XOs0/YWzMPeUWumykDC9rcQ9rpqkGB29Oyry1zpSquj8ZSkX65+5SQ5SUly6IGpMjB1vMqwH1A+BjzlwOCiIOeFQt7oWdcKmmo94xGGPDqaYgmglxjV 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.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Jun 2019 08:08:46 -0000 Date: 6 Jun 2019 10:08:44 +0200 Message-ID: From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> References: <20190605200619.2ED512014FE9B7@ary.local> <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 08:08:51 -0000 > Taking your note's plain language, you appear to be of the rather peculiar > view that specifying standards doesn't matter, since people won't follow > them. > > Looping is a classic problem. It has classic solutions. Getting the details > of one specified for this case is, of course, different from getting people > to adopt it, but the start is with specifying it. If people follow the spec there will be fewer loops, but it won't reduce the number to zero. Partly it's because not everyone follows the spec, partly because it is hard to anticipate all of the paths that can lead to indirect loops a->b->c->a or a->b->c->d->a. This is hardly limited to mail loops. The DNS specs say not to create CNAME loops, but indirect loops happen all the time so every resolver that follows CNAMEs needs loop breaking code. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jun 6 01:27:50 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C143B12019C for ; Thu, 6 Jun 2019 01:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 zHPUd11ueMnB for ; Thu, 6 Jun 2019 01:27:48 -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 9D86112015A for ; Thu, 6 Jun 2019 01:27:48 -0700 (PDT) Received: from [172.16.22.211] (80-64-77-66.static.acetelecom.hu [80.64.77.66]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x568TtE4003956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jun 2019 01:29:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1559809797; bh=CbKUx2YQhbPGNONjv2cuyG4fxS9HEl8wzCzqaFCxhnc=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=aQ59Ferhai2/B/5KYPech0QXASHIGn1HO1npwZGeGhbzuVEINadPtohGzdsHUUM0l 7FhGQYTSY7wVdCKIgK5YfwX2BhBlabzDxPuH8q/1hAuQ4ElTKOT7XSqfKy672fV7VI M+YuD7+PH8Z4t6BsSywg1fcZqKXoCv/klZEYQk38= To: John R Levine , dmarc@ietf.org References: <20190605200619.2ED512014FE9B7@ary.local> <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Message-ID: Date: Thu, 6 Jun 2019 10:27:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 08:27:50 -0000 On 6/6/2019 10:08 AM, John R Levine wrote: > If people follow the spec there will be fewer loops, but it won't reduce > the number to zero. Forgive me, but I believe there is currently no spec to follow. Yet. I took this thread as raising the issue that there needs to be an effort that specifies how to avoid dmarc report loops. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jun 6 03:39:02 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18300120086 for ; Thu, 6 Jun 2019 03:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=a4t6g24O; dkim=pass (1536-bit key) header.d=taugh.com header.b=Pb/okyir 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 tRY4mld2Txca for ; Thu, 6 Jun 2019 03:38:58 -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 CE40D120158 for ; Thu, 6 Jun 2019 03:38:57 -0700 (PDT) Received: (qmail 8326 invoked from network); 6 Jun 2019 10:38:56 -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=2084.5cf8ed40.k1906; i=johnl-iecc.com@submit.iecc.com; bh=G0IBJWbWLfD8bvmYfdxF9byBTpcrk04QgslYiY3jD5c=; b=a4t6g24OpX4uYROaeeonBsICj94K36279sENAqioG1lD4CjkWkaUGmVW3LUlzGtPXXjGAayV3fRd3rjL/VdrCi6qH34B3qH71nL0LWhChjz8ordUcP8mnesu8kLOvPwLtqo6uePHzawjaq02uxwRSqtAHqt9HkLNnH8bfWKeuWvdXxsh/+rYmrM+upvg7Y/oTjx6ytEp1LqFjqZ7er1FCKcSVrIxQBqgQ2SAdUMAHk/GMIgFSZ51X5IBvoLBhZCp 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=2084.5cf8ed40.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=G0IBJWbWLfD8bvmYfdxF9byBTpcrk04QgslYiY3jD5c=; b=Pb/okyirguBq7EzVuym50fDAwg9/lBJSyxX34JUn1sn9BhxOMmfTJ43ZHASMGGGsF7i5UUgUKEJ4a8SEnQVf5id5nLDSHpvrEqIEwpc/N2Fl3dAFEOR0ubhpWwZVmlvWPvnqoG1t69sB+9MUabZqWBXIU9tJk72vK/tcmdDFfpK01Q7lrGXCGZ7x9H0vlkJ7vh42Xn+xxiFX/PX9a+JvtXCvsF7fr/u7iRUnufCO7CH8gqwsxR/lhAQwyBsUvHF8 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.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Jun 2019 10:38:56 -0000 Date: 6 Jun 2019 12:38:54 +0200 Message-ID: From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: References: <20190605200619.2ED512014FE9B7@ary.local> <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 10:39:01 -0000 >> If people follow the spec there will be fewer loops, but it won't reduce >> the number to zero. > > Forgive me, but I believe there is currently no spec to follow. Yet. I took > this thread as raising the issue that there needs to be an effort that > specifies how to avoid dmarc report loops. As I thought I already said a few times, it would be a fine idea to offer advice to make DMARC reports less loop-prone. No, that will not prevent all loops so you need to do rate limiting, too. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jun 6 10:12:45 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E42E12008D for ; Thu, 6 Jun 2019 10:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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=verisign.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 3dc53CWJnxAI for ; Thu, 6 Jun 2019 10:12:42 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 0AC2812007A for ; Thu, 6 Jun 2019 10:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=639; q=dns/txt; s=VRSN; t=1559841162; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=EQmH+IwXNvnP3ZPNdqGoj9LWYPuGUU/cXiPnyCs2hvs=; b=G26AYXFe8ievRyQvlK88ElgGFPsS9LloR9R1AXZG2Md+VNpAmi1WX4jT QMSgYpWYwQhp8zzWkj12poMnYAm7O8UA+wWCIU2Xxug1/FeslWVHjIx9D gkZUz7oOLvnCzW5LdrUobtxGW3iswDoT5xpnX9ZghF8uz/fVNsGH910rB jfXIHUJ0ImmNQdeNvjSJPcGT7kmwkHZaWINUDRU4Cz7HjFLOC73L22u/z CexX+VC9SNzEfmwcKeUrrOCVPvfXYPGh5hf0V6MoIn2TWSFF4kUKDzylQ xp5fU1q4wzD7VdKXtwVEbKYAzWM9cCoCULQ3rR9NJaPvVGWdEKomSHcDa Q==; X-IronPort-AV: E=Sophos;i="5.63,560,1557187200"; d="scan'208";a="7899292" IronPort-PHdr: =?us-ascii?q?9a23=3ArW+r3BEKse90pbvYl7HueZ1GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ7zoc+wAkXT6L1XgUPTWs2DsrQY0rOQ6vy8EjVZud6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vMRm6txjdu8YZjIdtN6o91w?= =?us-ascii?q?fFqWZUdupLwm9lOUidlAvm6Meq+55j/SVQu/Y/+MNFTK73Yac2Q6FGATo/K2?= =?us-ascii?q?w669HluhfFTQuU+3sTSX4WnQZSAwjE9x71QJH8uTbnu+Vn2SmaOcr2Ta0oWT?= =?us-ascii?q?mn8qxmRgPkhDsBOjUk9mzcl85+g79BoB+5pxJx3ZPaYJ2bOvR9f6PSYdwUSm?= =?us-ascii?q?VaU8ZNTixBAJ+wY5cTA+YfO+tTsonzp0EJrRu7HQSgCuHhyjhMhn/yw6I61f?= =?us-ascii?q?8uHh/a0wwjB94FrWnao8nyNKcOTeC5wrTDwDLYb/NW3jf97IzIfQ4nof6XQ7?= =?us-ascii?q?1/bcnRxFIxFwzblFWQqJflPzKa1uQLqWSU8+1gVee2hmMhtgp/oSCvy98xho?= =?us-ascii?q?XVnI4Z11LJ+CtjzIooJdC1RlR3bNGgHZdIqi2WK5F6Tt4gTm10oio217ILtJ?= =?us-ascii?q?2hcCQXy5kr3xDfZOKEfoSU5x/uUeScLitkiH1/fb+zmgq9/lSlx+D8S8a7zl?= =?us-ascii?q?hKoy9Bn9bRq38CyRre4dWdRPRn5EeuwzOP2hjW6uFDPE87i7LWK4Ukwr4sjp?= =?us-ascii?q?oTtlnDHjPulEX2kqCWckIk9/C15ur7ervqu5+TOZd7hA7/LqgihNazAfokPQ?= =?us-ascii?q?gJRWib4f6w26f+8kHjXrVKlOY2kq/DvJ/GIsQbo7a1Aw5T0ok99xayFyqq3M?= =?us-ascii?q?gCkXUaLl9IdgiLg5XpNlzAOvz1AvOyj0ypkDhxxvDGOrPhAo/KLnjGiLrhZr?= =?us-ascii?q?Z960lYyAo3099f4YlbBa8dL/LwQULxqsLXDgU4MwyvwubnB9N92pkCVmKIB6?= =?us-ascii?q?+VKLnSvkOQ5uIzP+mMY5cYtyv4K/c//f7hkWQ0mV4Dcqm105sbcne4Hu5pIx?= =?us-ascii?q?bRXX25yNsEGH0BlgszUOKsj0eNG3YHa3O7RakU5zwnBsShF4iVFa63h7nUlg?= =?us-ascii?q?e8GplbYGpLAVPIWUzjcJmYEb9YcyKVJstslDYJXruJVYI71Aqvuwm8wL1ieL?= =?us-ascii?q?mHshYEvI7ugYAmr9bYkgs/oGR5?= X-IPAS-Result: =?us-ascii?q?A2HsBACeSPlc/zGZrQplHgEGBwaBZYQxs2MJAQEBAQEBA?= =?us-ascii?q?QEBBwETHAEBh0k4EwEDAQEBBAEBAQEDAQEBAoEGC4I6IoMwUQE+QiYBBBuuH?= =?us-ascii?q?4VHhGeBNItygUE+jwcEqRkDBgKCDpM1I4ITEIp7iWqNDpYwAgQCBAUCFYFmg?= =?us-ascii?q?Xpwgz2QUY9PgSEBAQ?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 6 Jun 2019 13:12:40 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Thu, 6 Jun 2019 13:12:40 -0400 From: "Hollenbeck, Scott" To: "dmarc@ietf.org" Thread-Topic: PSDs in draft-ietf-dmarc-psd Thread-Index: AdUciY2y4WRjNep5RxiJQapQPwT8pg== Date: Thu, 6 Jun 2019 17:12:40 +0000 Message-ID: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dmarc-ietf] PSDs in 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, 06 Jun 2019 17:12:43 -0000 I recently had a chance to read through draft-ietf-dmarc-psd. If I understa= nd it correctly (and I'm not sure that I do), the document suggests that it= 's possible for a TLD like ".com" to be a PSD and a TXT record like "_dmarc= .com" can be published in the com zone. I found this part of the draft conf= using because it's not possible to add TXT records like that to the com zon= e. It might help to explicitly note somewhere (perhaps in Section 2.2) that= there may be policy restrictions in place that disallow the publication of= DMARC policy records in some DNS zones, including some top-level domain zo= nes. Scott From btv1==060678adde5==fosterd@bayviewphysicians.com Thu Jun 6 10:09:15 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E87120225 for ; Thu, 6 Jun 2019 10:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6I_JUIerNUoP for ; Thu, 6 Jun 2019 10:09:12 -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 10FA3120194 for ; Thu, 6 Jun 2019 10:09:11 -0700 (PDT) X-ASG-Debug-ID: 1559840950-11fa3116c834e170001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 5G9a7TpHesEsbbRE (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Thu, 06 Jun 2019 13:09:10 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client 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=jtYc/oqC8okdMHzbR7qzqPLB8xO67eUtvOBFWQAiKk8=; b=bMosBrhArXeMBxOdhZQ/Xf6I0YJyZgH6nNOqOGugP1nBF3p4dpVT/fVUW7qr/qUxk AEIoO/epphxI+SHpQRV9n/AJe8kQG2gjOFPtMzLjltnqbED9wQprvMQkFjKE7Biow 5/hOYufdd2VJXfJnQ+MBw0Ea2G8KF6UBAw+dtLSyU= Received: by webmail.bayviewphysicians.com via HTTP; Thu, 6 Jun 2019 13:09:02 -0400 From: "Douglas E. Foster" To: , Date: Thu, 6 Jun 2019 13:09:02 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Mandatory Sender Authentication Reply-To: fosterd@bayviewphysicians.com Message-ID: <941abdbf28684283b972f69f25876220@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=c2c04e162353462d9627c5b4fca71275 X-Originating-IP: [192.168.1.239] In-Reply-To: <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> X-Exim-Id: 941abdbf28684283b972f69f25876220 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1559840950 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: 14382 X-Barracuda-BRTS-Status: 0 Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 06 Jun 2019 17:47:48 -0000 This is a multipart message in MIME format. --c2c04e162353462d9627c5b4fca71275 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >> 1. By 'sender', which actor in the sequence do you mean? The term is highly ambiguous. By Sender Authentication, I mean message "From Address" authentication. This involves two rules: The sending IP address is known to be authorized to send for the SMTP Sender-Address because of MX or SPF, and the SMTP Sender-Address is known to be authorized to send for the message from Address because of either domain alignment or a verifiable DKIM signature for the domain of the message From-Address. The message From-Address is what the user sees, so it seems important to know that the user is not being deceived by an impersonator. >> 2. Your certitude presumes an empirical foundation, given how often good theory does not make good practice. People have been working in this space for a very long time and one might have expected the industry to have latched on such a simple requirement were it that clear it was /the/ essential requirement. Please document the basis for your certitude. What I actually intend is that "a recipient has a viable option to implement mandatory sender authentication." This i equivalent to enforcing basic DMARC rules whether the sender has a DMARC policy or not. This requires: An email filter that understands SPF, DKIM, and DMARC. An email filter that provides local policy options to detect, evaluate, and override false positives. A sufficiently low level of false positives that the recipient organization is willing to commit the administrative resources to investigating and correcting false positives. These conditions are sorely lacking, as explained in the next section. >> 3. What made you think that 'sender' authentication is not already happening at a sufficient level? What is the basis for believing it isn't already being used by filtering agents well enough? I have been doing a market survey, and it suggests that many vendors do not understand the problem or do not believe it needs to be solved. I began with these minimal screening requirements: Source filtering: Able to block based on both IP address and Reverse DNS. A surprising number of vendors only supported one of these filters. Sender authentication: Able to enforce sender DMARC policies. (No requirement to support feedback processing) Able to override an incorrect SPF policy using a multi-factor rule (source server + sender domain). A surprising number of devices that supported DMARC filtering could not do ReverseDNS filtering. More recently, I realized that the only effective way to correct an SPF policy is to use SPF syntax. I have not yet seen any product that does so, but I have more products to review. For the first pass, I had no filtering criteria related to content filtering. Results ---------- These vendors could not meet all four criteria: Barracuda (appliance, hybrid, and cloud products) Sophos (3 appliance products, 2 cloud products) Edgewave Forcepoint Fortinet Trend Micro Dell SonicWall Symantec SpamExperts / SonicWall Mail Some of these were evaluated based on reviews of the administrative manuals, others based on a sales process. On the higher-end solutions: I discounted Cisco Talos and Proofpoint because their secure email solutions do domain spoofing. BAE Solutions was dropped because their sales process required me to sign a non-disclosure agreement. Based on what we did discuss, it did not appear that they could meet the four requirements. Kaspersky was ignored because of mistrust of the Russian government. The following products appeared to meet the minimum requirements, but for most of them I do not have access to the administrator manual until I commit to a product trial. Cloudswift Mimecast Fortinet FireEye I am in early discussions with AT&T / MessageLabs, but have no asssessment yet. >> 4. Consider the limitations to 'sender' authentication. I am spending a lot of time thinking about the limitations of sender authentication. For a spammer domain, SPF / DKIM / DMARC are easy. For impersonation, Friendly Name and embedded logo images can be pretty effective without violating SPF / DKIM / DMARC. This means that Sender Authentication may produce more false positives than true positives. Given the labor cost of addressing the mistakes, it is an open question whether the effort is worthwhile. For the moment, I am hoping so. I manage two very different mail streams, and the one that has higher spam levels appears to benefit from enforcing SPF and DMARC. Neither environment has products with adequate tools for implementing SPF exceptions, so I do not know how long I can leave the features enabled. Since you are involved in the Sender Authentication standards process, I assume you agree that Sender Authentication has potential to add value. To minimize false positives, I would like to see: Pressure on list forwarders to either not break signatures, or follow the IETF example of replacing the original from with the list domain and signing the new message with the list domain. Advice to senders to reduce signature complexity. In the general mail stream, the purpose of the DKIM signature is to authenticate the sender, and the protected data serves the purpose of a unique key for the signature process, to prevent replay attacks. Uniqueness should be achievable using three headers: To, From, and Date. Subject and Message-ID should not be used as they are two fields that are likely to be altered in transit. (Using DKIM signatures for content validation is only viable if the sender is known with confidence and an exception management process is in place. These conditions may exist for specific sender-receiver pairs, but they will not exist as a default condition.) But I have already been told that IETF is not interested in Recipient product problems, and is not concerned with security, which has left me very disappointed. Doug Foster --c2c04e162353462d9627c5b4fca71275 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
>> 1. By 'sender', which actor in the sequence do you mean? The = term is
highly ambiguous.
 
By Sender Authentication, I mean message "From Address&qu= ot; authentication.   This involves two rules:
  • The sending IP address is known to be authorized to send for t= he SMTP Sender-Address because of MX or SPF, and
  • the SMTP Sender-Address is known to be authorized to send for = the message from Address because of either
    • domain alignment or
    • a verifiable DKIM signature for the domain of the message Fro= m-Address. 
The message From-Address is what the user sees, so it seems im= portant to know that the user is not being deceived by an impersonator.

>> 2. Your certitude presumes an empirical foundation, given how ofte= n good
theory does not make good practice. People have been working in this
space for a very long time and one might have expected the industry to
have latched on such a simple requirement were it that clear it was
/the/ essential requirement. Please document the basis for your certitude.<= /div>
 
What I actually intend is that "a recipient has a viable option t= o implement mandatory sender authentication."
This i equivalent to enforcing basic DMARC rules whether the sender ha= s a DMARC policy or not.   This requires:
  • An email filter that understands SPF, DKIM, and DMARC.
  • An email filter that provides local policy options to detect, evaluate= , and override false positives.
  • A sufficiently low level of false positives that the recipient organiz= ation is willing to commit the administrative resources to investigating an= d correcting false positives.
These conditions are sorely lacking, as explained in the next section.=

>> 3. What made you think that 'sender' authentication is not already=
happening at a sufficient level? What is the basis for believing it
isn't already being used by filtering agents well enough?
 
I have been doing a market survey, and it suggests that many vendors d= o not understand the problem or do not believe it needs to be solved. = I began with these minimal screening requirements:
 
Source filtering:
   Able to block based on both IP address and Reverse DNS.&n= bsp;
 
A surprising number of vendors only supported one of these filter= s.
 
Sender authentication:
   Able to enforce sender DMARC policies.   (No re= quirement to support feedback processing)
   Able to override an incorrect SPF policy using a multi-fa= ctor rule (source server + sender domain).
 
A surprising number of devices that supported DMARC filtering could no= t do ReverseDNS filtering.
 
More recently, I realized that the only effective way to correct an SP= F policy is to use SPF syntax.   I have not yet seen any product = that does so, but I have more products to review.
 
For the first pass, I had no filtering criteria related to content fil= tering.
 
Results
----------
These vendors could not meet all four criteria:
  • Barracuda (appliance, hybrid, and cloud products)
  • Sophos (3 appliance products, 2 cloud products)
  • Edgewave
  • Forcepoint
  • Fortinet
  • Trend Micro
  • Dell SonicWall
  • Symantec
  • SpamExperts / SonicWall Mail
Some of these were evaluated based on reviews of the administrative ma= nuals, others based on a sales process.
 
On the higher-end solutions:
 
I discounted Cisco Talos and Proofpoint because their secure email sol= utions do domain spoofing.
 
BAE Solutions was dropped because their sales process required me to s= ign a non-disclosure agreement.   Based on what we did discuss, i= t did not appear that they could meet the four requirements.
 
Kaspersky was ignored because of mistrust of the Russian government.
 
The following products appeared to meet the minimum requirements,= but for most of them I do not have access to the administrator manual unti= l I commit to a product trial.
  • Cloudswift
  • Mimecast
  • Fortinet
  • FireEye
I am in early discussions with AT&T / MessageLabs, but have no ass= sessment yet.
 
 
>> 4. Consider the limitations to 'sender' authentication.

I am spending a lot of time thinking about the limitations of sender authen= tication.   For a spammer domain, SPF / DKIM / DMARC are easy.&nb= sp;  For impersonation, Friendly Name and embedded logo images can be = pretty effective without violating SPF / DKIM / DMARC.
 
This means that Sender Authentication may produce more false positives= than true positives.   Given the labor cost of addressing the mi= stakes, it is an open question whether the effort is worthwhile.  &nbs= p;For the moment, I am hoping so.  I manage two very different mail st= reams, and the one that has higher spam levels appears to benefit from enfo= rcing SPF and DMARC.  Neither environment has products with adequate t= ools for implementing SPF exceptions, so I do not know how long I can leave= the features enabled.   Since you are involved in the Sender Aut= hentication standards process, I assume you agree that Sender Authenticatio= n has potential to add value.
 
To minimize false positives, I would like to see:
  • Pressure on list forwarders to either not break signatures, or follow = the IETF example of replacing the original from with the list domain and si= gning the new message with the list domain.
     
  • Advice to senders to reduce signature complexity.   In the g= eneral mail stream, the purpose of the DKIM signature is to authenticate th= e sender, and the protected data serves the purpose of a unique key for the= signature process, to prevent replay attacks.   Uniqueness shoul= d be achievable using three headers:  To, From, and Date.   = Subject and Message-ID should not be used as they are two fields that are l= ikely to be altered in transit.    (Using DKIM signatures for con= tent validation is only viable if the sender is known with confidence and a= n exception management process is in place.  These conditions may= exist for specific sender-receiver pairs, but they will not exist as a def= ault condition.)
But I have already been told that IETF is not interested in Recipient = product problems, and is not concerned with security, which has left me ver= y disappointed.
 
 
Doug Foster
 
--c2c04e162353462d9627c5b4fca71275-- From nobody Thu Jun 6 11:52:41 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE0A120114 for ; Thu, 6 Jun 2019 11:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ftld.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 pPXxdgIxyApa for ; Thu, 6 Jun 2019 11:52:38 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 9628D1200C1 for ; Thu, 6 Jun 2019 11:52:38 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id x22so1645033itl.2 for ; Thu, 06 Jun 2019 11:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftld.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KDs8Qgi+4JW4cSriyg7N2+ZC3qQSn5n0lgKM7nl3pG4=; b=T2zSTUO7z1aQfkFV9o/ciEPTMdkljdmREynd+1Sw1NMbSt9zJ6+N5vRYH47MK0ZStt WfxP8BqENcBvvUOM+sC1RKouAqZOEYaUqQf+7fFDZet/MfnvCgFIZgR8TqBjhqqi36XD XK4lTIHJTerjR0hcUyNjOeZA0UnmehzM3DssQ= 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=KDs8Qgi+4JW4cSriyg7N2+ZC3qQSn5n0lgKM7nl3pG4=; b=XufOkffp7F4PTzfl+KAF+4a4JhJUQlm8MwQY4XRecQCJONALTXjjXHMiPgOhB/s+p9 sly8iNXxg7CL/qtVEXU25PudPuPLwzL8njGSrhI3xzCFSudqybJHStpsHA9wVOyFqtbE bmdPXzOpPltCRuT+EO6Fa7oOHSDyCU13FxwOXrUrOX1EcXA+ZXaB3APgMz/xQfHMN1JZ GHlWrgAxrsO+J0djzY2pf+y23owoqql72RH15kiOUFlRKh881gCcRtme3wpohbbZorN7 lPil5JrYi2T9aMmrZ7Y9IL0g9JplecSqu809Y8E30nhgimFbsNJOuwg1QlhrnOJv9aaS L2KA== X-Gm-Message-State: APjAAAW00yVAYUetvrdkWnYRCHdQU0DZATt4GJ9NW/y+raVb/RVdmzQU MadJKweR89qnCNYpjnxJ3XJF6tsP1wCmfx68qQ/xYt8I X-Google-Smtp-Source: APXvYqwOxVOnHKVyb5nV6y3bIdnU/nJ2DIKKGYdRU/gRaqF78Hu8gAgnWn5a/oVFKKiivYjtLGlTJOrPWYM0s52u47o= X-Received: by 2002:a24:3556:: with SMTP id k83mr1231605ita.19.1559847157528; Thu, 06 Jun 2019 11:52:37 -0700 (PDT) MIME-Version: 1.0 References: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> In-Reply-To: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> From: Craig Schwartz Date: Thu, 6 Jun 2019 14:52:26 -0400 Message-ID: To: "Hollenbeck, Scott" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000baaeef058aac37e6" Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 06 Jun 2019 18:52:40 -0000 --000000000000baaeef058aac37e6 Content-Type: text/plain; charset="UTF-8" >On Thursday, June 6, 2019 at 1:12 PM EDT Scott Hollenbeck wrote: >I recently had a chance to read through draft-ietf-dmarc-psd. If I understand it correctly (and I'm not sure that I do), the document suggests that it's possible for a TLD like ".com" >to be a PSD and a TXT record like "_dmarc.com" can be published in the com zone. I found this part of the draft confusing because it's not possible to add TXT records like that >to the com zone. It might help to explicitly note somewhere (perhaps in Section 2.2) that there may be policy restrictions in place that disallow the publication of DMARC policy >records in some DNS zones, including some top-level domain zones. The purpose of the document is to convey technically how PSD DMARC can be accomplished rather than who can or cannot undertake this due to policy considerations. As the operator of .BANK and .INSURANCE, fTLD initiated this stream of work with the IEFT because of the explicit prohibition by ICANN from inserting TXT records in the DNS. The goal is to get to an RFC that specifies the technical aspect of PSD DMARC and ultimately seek ICANN's approval to allow publication of such a record in the DNS. In contrast, gTLDs not under contract with ICANN such as .MIL and .GOV, who are both involved in this work, do not have a contractual relationship with ICANN and thus are not prohibited from this activity, and the same goes for ccTLDs. Craig *--* Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE Office: +1 202 589 2532 Mobile: +1 202 236 1154 Skype: craig-schwartz www.fTLD.com On Thu, Jun 6, 2019 at 1:12 PM Hollenbeck, Scott wrote: > I recently had a chance to read through draft-ietf-dmarc-psd. If I > understand it correctly (and I'm not sure that I do), the document suggests > that it's possible for a TLD like ".com" to be a PSD and a TXT record like > "_dmarc.com" can be published in the com zone. I found this part of the > draft confusing because it's not possible to add TXT records like that to > the com zone. It might help to explicitly note somewhere (perhaps in > Section 2.2) that there may be policy restrictions in place that disallow > the publication of DMARC policy records in some DNS zones, including some > top-level domain zones. > > Scott > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000baaeef058aac37e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>On Thursday, June 6, 2019= at 1:12 PM EDT Scott Hollenbeck wrote:
>I recently had a chance to read through draf= t-ietf-dmarc-psd. If I understand it correctly (and I'm not sure that I= do), the document suggests that it's possible for a TLD like ".co= m" >to be a PSD and a TXT record like "_dmarc.com" can be published in the com zone. I found this pa= rt of the draft confusing because it's not possible to add TXT records = like that >to the com zone. It might help to explicitly note somewhere (= perhaps in Section 2.2) that there may be policy restrictions in place that= disallow the publication of DMARC policy >records in some DNS zones, in= cluding some top-level domain zones.=C2=A0=C2=A0
<= br>
The purpose of the document is to convey technically how PSD DMARC can = be accomplished rather than who can or cannot undertake this due to policy = considerations. As the operator of .BANK and .INSURANCE, fTLD initiated thi= s stream of work with the IEFT because of the explicit prohibition by ICANN= from inserting TXT records in the DNS. The goal is to get to an RFC that s= pecifies the technical aspect of PSD DMARC and ultimately seek ICANN's = approval to allow publication of such a record in the DNS. In contrast, gTL= Ds not under contract with ICANN such as .MIL and .GOV, who are both involv= ed in this work, do not have a contractual relationship with ICANN and thus= are not prohibited from this activity, and the same goes for ccTLDs.
=

<= /div>
= Craig=C2=A0

=
--

Craig Schwartz
<= /div>
Managing Dire= ctor
fTLD Registry Serv= ices | .BANK & .INSURANCE
Office: +1 202 589 2532
Mobile: +1 202 236 1154
Skype: craig-schwartz




=
=

On Thu, Jun 6, 2019 at 1:12 PM Hollenbeck, Scott <shollenbeck=3D40verisign.c= om@dmarc.ietf.org> wrote:
I recently had a chance to read through draft-ietf-dmarc-p= sd. If I understand it correctly (and I'm not sure that I do), the docu= ment suggests that it's possible for a TLD like ".com" to be = a PSD and a TXT record like "_dmarc.com" can be published in the com z= one. I found this part of the draft confusing because it's not possible= to add TXT records like that to the com zone. It might help to explicitly = note somewhere (perhaps in Section 2.2) that there may be policy restrictio= ns in place that disallow the publication of DMARC policy records in some D= NS zones, including some top-level domain zones.

Scott

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000baaeef058aac37e6-- From nobody Thu Jun 6 15:31:00 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE88312013D for ; Thu, 6 Jun 2019 15:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li3rat7CCNrp for ; Thu, 6 Jun 2019 15:30:56 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 18E5E12000F for ; Thu, 6 Jun 2019 15:30:56 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id b17so187295wrq.11 for ; Thu, 06 Jun 2019 15:30:56 -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=6O8niS9QbaXQZPsBbKekQlAX3nSKKbr1L9tfUbsB9n8=; b=q+8ZfEiAba6rLAdpzbXLUSekWxJ91E2uwBH6jZiptQPnv8JYK0nLOdEnynZIJihQ42 BbSaielfk8csRRePRNUJ6ewkBPdBJ6BRDfgzVxM2IaWo1ksQi6a/vYJZPkdyy4HapKU5 ReXAvuw3pNVQWyBntkdfCwi3JvU2zAJcAUiL+3sfVWhRjm3+7kvpTvq8/K2yReDr8EcJ ms9v38vlJhe8rQZqUcj6IQndfe2/Q1UWQvxgyPxO5EretO3WVdooDvbPJXYpAMlGgBv1 OvWavhJeFMyBQDh4PJu8HpDOTfHgGQOFvZP79CK7GT7UKaR0jxgCqeiL9MJetUEejNyq rIsQ== 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=6O8niS9QbaXQZPsBbKekQlAX3nSKKbr1L9tfUbsB9n8=; b=tNxdAgtlA+l+EzJgBN2uKMxNyJX/gXDBJFJL9INr7TAo65e1pScLe4qT1XkdebqPZ8 KDhG+JOz1Kfjvet6yH+a71xrHckP00r4PPujT0+0QN1ZRfQmSKq+/IJLFJlrIKjfboYZ O1QaqHPCrjER0x8uKizaejbjdaitHIhw65BE5eRLngFlnU1sIyImFNAFC+PEFiYNpwlh wR5Q6/nysIqECWszZ8+yM5jXrDLEXH0uL6iqKIN/A890wpFXnqS3OahC6pHIsir5qn9y SCcb+xACjIUlXFn4m4MixTuuRyEqBMmgLVYXeOKNLg85NTgqqo+bQs89M0AejBF8GmnJ DJyw== X-Gm-Message-State: APjAAAU8oXdpF8TCrWHLjhu5RHbxsLcmoRg7q340cSvOhnETXF/CCj0w TNsV5EQ1cDpZ9NZ1JRkoIDDACYSuNKJDMPcT9e9wMA== X-Google-Smtp-Source: APXvYqylRQRnDxDZdx9hpc/auGbgcuQcQ7ZqxRHBq2PHR0Yp44P7AOo2vIGoUf3T1rGJ0yxRxYC4A80t8WYxKpeUFgc= X-Received: by 2002:a5d:4cc3:: with SMTP id c3mr4482626wrt.259.1559860254177; Thu, 06 Jun 2019 15:30:54 -0700 (PDT) MIME-Version: 1.0 References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> In-Reply-To: <941abdbf28684283b972f69f25876220@bayviewphysicians.com> From: Dotzero Date: Thu, 6 Jun 2019 18:30:45 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000597c53058aaf44fb" Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 06 Jun 2019 22:30:59 -0000 --000000000000597c53058aaf44fb Content-Type: text/plain; charset="UTF-8" Comments in-line. On Thu, Jun 6, 2019 at 1:47 PM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > >> 1. By 'sender', which actor in the sequence do you mean? The term is > highly ambiguous. > > By Sender Authentication, I mean message "From Address" authentication. > This involves two rules: > > - The sending IP address is known to be authorized to send for the > SMTP Sender-Address because of MX or SPF, and > - the SMTP Sender-Address is known to be authorized to send for the > message from Address because of either > - domain alignment or > - a verifiable DKIM signature for the domain of the message > From-Address. > > The message From-Address is what the user sees, so it seems important to > know that the user is not being deceived by an impersonator. > This is absolutely incorrect. Making sweeping generalizations leads to bad outcomes. There are MUAs that show the display name. > > >> 2. Your certitude presumes an empirical foundation, given how often good > theory does not make good practice. People have been working in this > space for a very long time and one might have expected the industry to > have latched on such a simple requirement were it that clear it was > /the/ essential requirement. Please document the basis for your certitude. > > What I actually intend is that "a recipient has a viable option to > implement mandatory sender authentication." > This i equivalent to enforcing basic DMARC rules whether the sender has a > DMARC policy or not. This requires: > > - An email filter that understands SPF, DKIM, and DMARC. > - An email filter that provides local policy options to detect, > evaluate, and override false positives. > - A sufficiently low level of false positives that the recipient > organization is willing to commit the administrative resources to > investigating and correcting false positives. > > These conditions are sorely lacking, as explained in the next section. > I think you should create such a product. You can then compete in the marketplace of ideas. > > >> 3. What made you think that 'sender' authentication is not already > happening at a sufficient level? What is the basis for believing it > isn't already being used by filtering agents well enough? > > I have been doing a market survey, and it suggests that many vendors do > not understand the problem or do not believe it needs to be solved. I > began with these minimal screening requirements: > > The IETF is focused on interoperability. What you are proposing in this section is that somehow the IETF can force vendors to implement features/functionality in their offerings that is not related to interoperability. If their customer were clamoring for it I guarantee you that it would be on their product roadmap. > Source filtering: > Able to block based on both IP address and Reverse DNS. > > There's this crazy thing called RPZ. It is commonly used with RBLs. You might want to take a look at it. > A surprising number of vendors only supported one of these filters. > > Sender authentication: > Able to enforce sender DMARC policies. (No requirement to support > feedback processing) > Able to override an incorrect SPF policy using a multi-factor rule > (source server + sender domain). > A receiving system can implement whatever local policy it wants. As far as I know, there is no Internet police to enforce your demands on what local policy is implemented. > > A surprising number of devices that supported DMARC filtering could not do > ReverseDNS filtering. > > More recently, I realized that the only effective way to correct an SPF > policy is to use SPF syntax. I have not yet seen any product that does > so, but I have more products to review. > > For the first pass, I had no filtering criteria related to content > filtering. > > Results > ---------- > These vendors could not meet all four criteria: > > - Barracuda (appliance, hybrid, and cloud products) > - Sophos (3 appliance products, 2 cloud products) > - Edgewave > - Forcepoint > - Fortinet > - Trend Micro > - Dell SonicWall > - Symantec > - SpamExperts / SonicWall Mail > > Some of these were evaluated based on reviews of the administrative > manuals, others based on a sales process. > > On the higher-end solutions: > > I discounted Cisco Talos and Proofpoint because their secure email > solutions do domain spoofing. > > BAE Solutions was dropped because their sales process required me to sign > a non-disclosure agreement. Based on what we did discuss, it did not > appear that they could meet the four requirements. > > Kaspersky was ignored because of mistrust of the Russian government. > > The following products appeared to meet the minimum requirements, but for > most of them I do not have access to the administrator manual until I > commit to a product trial. > > - Cloudswift > - Mimecast > - Fortinet > - FireEye > > I am in early discussions with AT&T / MessageLabs, but have no asssessment > yet. > I'm sorry to burst your bubble, but the Internet is not all about your personal needs, wants and desires. > > > >> 4. Consider the limitations to 'sender' authentication. > > I am spending a lot of time thinking about the limitations of sender > authentication. For a spammer domain, SPF / DKIM / DMARC are easy. For > impersonation, Friendly Name and embedded logo images can be pretty > effective without violating SPF / DKIM / DMARC. > Contrary to your opinion, email authentication is not about stopping spammers. For example, DMARC was created to mitigate direct domain abuse in the mail stream. In fact, miscreants were quicker to adopt SPF/DKIM and DMARC than legitimate senders. This did have the effect of allowing the assignment of reputation to sending domains. > > This means that Sender Authentication may produce more false positives > than true positives. Given the labor cost of addressing the mistakes, it > is an open question whether the effort is worthwhile. For the moment, I > am hoping so. I manage two very different mail streams, and the one that > has higher spam levels appears to benefit from enforcing SPF and DMARC. > Neither environment has products with adequate tools for implementing SPF > exceptions, so I do not know how long I can leave the features enabled. > Since you are involved in the Sender Authentication standards process, I > assume you agree that Sender Authentication has potential to add value. > How large a corpus of mail did you evaluate in making your assertion about false positives versus true positives? I assume you are aware that there are people on this list who have examined varieties of different types of mail streams comprising a corpus of billions of emails. > > To minimize false positives, I would like to see: > > - Pressure on list forwarders to either not break signatures, or > follow the IETF example of replacing the original from with the list domain > and signing the new message with the list domain. > > - Advice to senders to reduce signature complexity. In the general > mail stream, the purpose of the DKIM signature is to authenticate the > sender, and the protected data serves the purpose of a unique key for the > signature process, to prevent replay attacks. Uniqueness should be > achievable using three headers: To, From, and Date. Subject and > Message-ID should not be used as they are two fields that are likely to be > altered in transit. (Using DKIM signatures for content validation is > only viable if the sender is known with confidence and an exception > management process is in place. These conditions may exist for specific > sender-receiver pairs, but they will not exist as a default condition.) > > I love when someone who self admittedly has little or no experience in a subject such as email standards and interoperability joins a list and starts lecturing people on how things should/must be. > > > But I have already been told that IETF is not interested in Recipient > product problems, and is not concerned with security, which has left me > very disappointed. > And yet you persist. If you have a product problem you really need to speak with your vendor. If no vendor supports your needs then perhaps you might consider it a market opportunity and do a startup. There are participants and workgroups within IETF that are concerned with security, but perhaps not with your notion of what security should be. Use TLS much? Have a good day and good luck with your endeavors. Michael Hammer > --000000000000597c53058aaf44fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments in-line.


On Thu, Jun 6, 2019 = at 1:47 PM Douglas E. Foster <fosterd@bayviewphysicians.com> wrote:
>> 1. By 'sender', which actor in the sequence do you mean= ? The term is
highly ambiguous.
=C2=A0
By Sender Authentication, I mean message "From Address" auth= entication.=C2=A0 =C2=A0This involves two rules:
  • The sending IP address is known to be authorized to send for the SMTP = Sender-Address because of MX=C2=A0or SPF, and
  • the SMTP Sender-Address is known to be authorized to send for the mess= age from Address because of either
    • domain alignment or
    • a verifiable DKIM signature for the domain of the message From-Addres= s.=C2=A0
The message From-Address is what the user sees, so it seems important = to know that the user is not being deceived by an impersonator.

This is absolutely incorrect. Maki= ng sweeping generalizations leads to bad outcomes. There are MUAs that show= the display name.
=C2=A0

>> 2. Your certitude presumes an empirical foundation, given how ofte= n good
theory does not make good practice. People have been working in this
space for a very long time and one might have expected the industry to
have latched on such a simple requirement were it that clear it was
/the/ essential requirement. Please document the basis for your certitude.<= /div>
=C2=A0
What I actually intend is that "a recipient has a viable option t= o implement mandatory sender authentication."
This i equivalent to enforcing basic DMARC rules whether the sender ha= s a DMARC policy or not.=C2=A0 =C2=A0This requires:
  • An email filter that understands SPF, DKIM, and DMARC.
  • An email filter that provides local policy options to detect, evaluate= , and override false positives.
  • A sufficiently low level of false positives that the recipient organiz= ation is willing to commit the administrative resources to investigating an= d correcting false positives.
These conditions are sorely lacking, as explained in the next section.=

I think you should create suc= h a product. You can then compete in the marketplace of ideas.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-= left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le= ft-style:solid">

>> 3. What made you think that 'sender' authentication is not= already
happening at a sufficient level? What is the basis for believing it
isn't already being used by filtering agents well enough?
=C2=A0
I have been doing a market survey, and it suggests that many vendors d= o not understand the problem or do not believe it needs to be solved.=C2=A0= I began with these minimal screening requirements:
=C2=A0

The IETF is focuse= d on interoperability. What you are proposing in this section is that someh= ow the IETF can force vendors to implement features/functionality in their = offerings that is not related to interoperability. If their customer were c= lamoring for it I guarantee you that it would be on their product roadmap.<= /div>
=C2=A0
Source filtering:
=C2=A0 =C2=A0Able to block based on both IP address and Reverse DNS.= =C2=A0
=C2=A0

There's this c= razy thing called RPZ. It is commonly used with RBLs. You might want to tak= e a look at it.
=C2=A0
A surprising number of vendors only supported=C2=A0one of these filter= s.
=C2=A0
Sender authentication:
=C2=A0 =C2=A0Able to enforce sender DMARC policies.=C2=A0 =C2=A0(No re= quirement to support feedback processing)
=C2=A0 =C2=A0Able to override an incorrect SPF policy using a multi-fa= ctor rule (source server + sender domain).
A receiving system can implement whatever local policy it want= s. As far as I know, there is no Internet police to enforce your demands on= what local policy is implemented.
=C2=A0
=
=C2=A0
A surprising number of devices that supported DMARC filtering could no= t do ReverseDNS filtering.
=C2=A0
More recently, I realized that the only effective way to correct an SP= F policy is to use SPF syntax.=C2=A0 =C2=A0I have not yet seen any product = that does so, but I have more products to review.
=C2=A0
For the first pass, I had no filtering criteria related to content fil= tering.
=C2=A0
Results
----------
These vendors could not meet all four criteria:
  • Barracuda (appliance, hybrid, and cloud products)
  • Sophos (3 appliance products, 2 cloud products)
  • Edgewave
  • Forcepoint
  • Fortinet
  • Trend Micro
  • Dell SonicWall
  • Symantec
  • SpamExperts / SonicWall Mail
Some of these were evaluated based on reviews of the administrative ma= nuals, others based on a sales process.
=C2=A0
On the higher-end solutions:
=C2=A0
I discounted Cisco Talos and Proofpoint because their secure email sol= utions do domain spoofing.
=C2=A0
BAE Solutions was dropped because their sales process required me to s= ign a non-disclosure agreement.=C2=A0 =C2=A0Based on what we did discuss, i= t did not appear that they could meet the four requirements.
=C2=A0
Kaspersky was ignored because of mistrust of the Russian government.
=C2=A0
The following=C2=A0products appeared to meet the minimum requirements,= but for most of them I do not have access to the administrator manual unti= l I commit to a product trial.
  • Cloudswift
  • Mimecast
  • Fortinet
  • FireEye
I am in early discussions with AT&T / MessageLabs, but have no ass= sessment yet.

I'm sorry to= burst your bubble, but the Internet is not all about your personal needs, = wants and desires.=C2=A0
=C2=A0
=C2=A0
>> 4. Consider the limitations to 'sender' authenticatio= n.

I am spending a lot of time thinking about the limitations of sender authen= tication.=C2=A0 =C2=A0For a spammer domain, SPF / DKIM / DMARC are easy.=C2= =A0 =C2=A0For impersonation, Friendly Name and embedded logo images can be = pretty effective without violating SPF / DKIM / DMARC.

Contrary to your opinion, email authentication is = not about stopping spammers. For example, DMARC was created to mitigate dir= ect domain abuse in the mail stream. In fact, miscreants were quicker to ad= opt SPF/DKIM and DMARC than legitimate senders. This did have the effect of= allowing the assignment of reputation to sending domains.=C2=A0
=C2=A0
This means that Sender Authentication may produce more false positives= than true positives.=C2=A0 =C2=A0Given the labor cost of addressing the mi= stakes, it is an open question whether the effort is worthwhile.=C2=A0 =C2= =A0For the moment, I am hoping so.=C2=A0 I manage two very different mail s= treams, and the one that has higher spam levels appears to benefit from enf= orcing SPF and DMARC.=C2=A0 Neither environment has products with adequate = tools for implementing SPF exceptions, so I do not know how long I can leav= e the features enabled.=C2=A0 =C2=A0Since you are involved in the Sender Au= thentication standards process, I assume you agree that Sender Authenticati= on=C2=A0has potential to add value.

<= /div>
How large a corpus of mail did you evaluate in making your assert= ion about false positives versus true positives? I assume you are aware tha= t there are people on this list who have examined varieties of different ty= pes of mail streams comprising a corpus of billions of emails. =C2=A0
=
=C2=A0
To=C2=A0minimize false positives, I would like to see:
  • Pressure on list forwarders to either not break signatures, or follow = the IETF example of replacing the original from with the list domain and si= gning the new message with the list domain.
    =C2=A0
  • Advice to senders to reduce signature complexity.=C2=A0 =C2=A0In the g= eneral mail stream, the purpose of the DKIM signature is to authenticate th= e sender, and the protected data serves the purpose of a unique key for the= signature process, to prevent replay attacks.=C2=A0 =C2=A0Uniqueness shoul= d be achievable using three headers:=C2=A0 To, From, and Date.=C2=A0 =C2=A0= Subject and Message-ID should not be used as they are two fields that are l= ikely to be altered in transit.=C2=A0 =C2=A0 (Using DKIM signatures for con= tent validation is only viable if the sender is known with confidence and a= n exception management process is in place.=C2=A0 These=C2=A0conditions may= exist for specific sender-receiver pairs, but they will not exist as a def= ault condition.)

I love wh= en someone who self admittedly has little or no experience in a subject suc= h as email standards and interoperability joins a list and starts lecturing= people on how things should/must be.
=C2=A0
But I have already been told that IETF is not interested in Recipient = product problems, and is not concerned with security, which has left me ver= y disappointed.

And yet you pe= rsist. If you have a product problem you really need to speak with your ven= dor. If no vendor supports your needs then perhaps you might consider it a = market opportunity and do a startup. There are participants and workgroups = within IETF that are concerned with security, but perhaps not with your not= ion of what security should be. Use TLS much?=C2=A0

Have a good day and good luck with your endeavors.

Michael Hammer
--000000000000597c53058aaf44fb-- From nobody Fri Jun 7 04:03:06 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8E51201D7 for ; Fri, 7 Jun 2019 04:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=verisign.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 zm_PEkdHm-Tn for ; Fri, 7 Jun 2019 04:03:02 -0700 (PDT) Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 2437712008A for ; Fri, 7 Jun 2019 04:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10598; q=dns/txt; s=VRSN; t=1559905382; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=+9uMMHJC2T9WX74tYtyRKy156M42bi8F6KzQsYTOt/Y=; b=PQ5UTIop4syPuTwsxZWikNeh9qN4D8UoFB8A7dyQffTPMti2xrDYd2hS JHEzYgZ+6SPCJnV51LbyjBVu4YMW2ieJTDD1sXSuNe+cW2dgLhXk/nR8Z 5/ZEasUtPDg+IsG1lb3ew7tcneGqGnWvvBpiMm3d32CM5ubPOG4lJIEZe Fu0tun+RFaqs/+iArE0VDUiV7qZXdQv6Jeio9KQseT/xdZzl3sew34f7I nb+NO2AawZ5rh2wEf34jmUVVcpE3ul0b8QeS857QoFTJsdRn/BiTVdADs E4mZPWCS88oYI6l2CdG3Ed/l++9Xs4NYNdXcdfqUJe4ox+vzSOqohsSW7 g==; X-IronPort-AV: E=Sophos;i="5.63,562,1557201600"; d="scan'208,217";a="7741140" IronPort-PHdr: =?us-ascii?q?9a23=3A41TtiRxBAtaO3LHXCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd0uoXKvad9pjvdHbS+e9qxAeQG9mCsrQd17Sd6PqocFdDyK7JiGoFfp1IWk?= =?us-ascii?q?1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBA?= =?us-ascii?q?j0OxZrKeTpAI7SiNm82/yv95HJbAhEmSexbalvIBi5rAjduccbjZV/Iast1x?= =?us-ascii?q?XFpWdFdf5Lzm1yP1KTmBj85sa0/JF99ilbpuws+c1dX6jkZqo0VbNXAigoPG?= =?us-ascii?q?Az/83rqALMTRCT6XsGU2UZiQRHDg7Y5xznRJjxsy/6tu1g2CmGOMD9UL45VS?= =?us-ascii?q?i+46ptVRTljjoMOTwk/2HNksF+jLxVrg+9pxJxwIDUboOaNPticazSZt4VX3?= =?us-ascii?q?ZNXsRLWiBdHo+xbY0CBPcBM+ZCqIn9okMDoRW8CwmrAOPvziFHhnnt0qIkz+?= =?us-ascii?q?shEhnK1xE9Ed0St3TUsMn1OKkPWu2y16nIzTLDb/dS2Tjj7ojHaQ4uru2PXb?= =?us-ascii?q?9rb8re11MvFwLejlWRpozlOSmZ2fgKs2ie9udtU/+khWAgqwF0uDevx8Esh5?= =?us-ascii?q?HUiYIQ0F/E7zl2zJwpKt2/TU52Z8OvHphItyyCKod6XtkuT3xqtSs00LEKpJ?= =?us-ascii?q?62cSYQxJkowxPTc+GLf5SS7h7+VuudPS10iG9qdb+8nRq+7EutxvXyVsaq01?= =?us-ascii?q?tGsi9In9zOu38RyxDc8M2KRuZh8Ui93DuC1x3c5f9KIU0xkafUNoMuzaA2m5?= =?us-ascii?q?EOq0rMBDX2l1/zjKKOc0Uk/fWn5Pr/b7X9o5+cK5d0igbjMqQygsC/Afo3Mg?= =?us-ascii?q?wJX2WD5OmyyKXt8VD5T7tSgfM5k7XVvI7AKcQFuqG5BBVV0p455xmlEjiqys?= =?us-ascii?q?oYnWMcLFJDYh6Ik4/pO1TWLPD5C/ewnUisnS92y/zaJLHtH5fAI3bZnLv8fb?= =?us-ascii?q?tw5VRQxQU3wNxH4pJbELABIPb9Wk/rs9zYCwc0Mxe0w+bgDNV90p0RWWSUDa?= =?us-ascii?q?CHLKzSskSF5vwxLOmWZY8Vozf9K/cj5/L0kXA5nlodcbGz3ZQLcHC4AuhmI0?= =?us-ascii?q?KBbHXwmNcOC2YKvgUmQeHllFGCXyJTZ3KvUK4m+j47D4emAJzeSYComrOBxj?= =?us-ascii?q?u0EodXZm9YFlCMH23kd4KeW/cDcCiSONNukiQYVbi9TI8szQyhtArgxLp9Mu?= =?us-ascii?q?XZ4SwYuoz/1Nh7/eHTkgsy9TMnR/iahiuGVWh1kTZUHzEq2Kw5qkt44luG2L?= =?us-ascii?q?Jzxf1VCdIV4OlGGE9uPoTVzuMvV4j8RgbNONyOTX6qR9y8CncwQ84/hdgUbB?= =?us-ascii?q?AuNc+li0WJ/y2uB7ITnbGAB9h8yanbw2S7b5Jmy3HC0KQnhVQtQeNROHenna?= =?us-ascii?q?9w8U7YAIufwBbRrLqjaalJhH2Fz2yE12fb5Ew=3D?= X-IPAS-Result: =?us-ascii?q?A2HgAgDPQ/pc/zGZrQpPFhwBAQEEAQEHBAEBgWWBD1OBG?= =?us-ascii?q?YEsCoQLg0qOfYI7mloJAQEBAQEBAQEBBwEbFAEBhEACF4J3OBMBAwEBAQQBA?= =?us-ascii?q?QEBAwEBAQKBBQELgjoigVMsNzkBAQEBAyMKRQcQAgEIEQQBARQXAgICMB0IA?= =?us-ascii?q?QEEDgUIgxuBHagigTGDdYFShHCBNItygUE+gRGDEj6CYQSBHIEBgkyCWASOI?= =?us-ascii?q?YRslhcDBgKCDoZDjHYjgiRpihOJcY0PhxOPIwIEAgQFAhWBZoF6cIM8CYV2i?= =?us-ascii?q?lNyAY43gSEBAQ?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 7 Jun 2019 07:03:00 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Fri, 7 Jun 2019 07:03:00 -0400 From: "Hollenbeck, Scott" To: "craig=40ftld.com@dmarc.ietf.org" CC: "dmarc@ietf.org" Thread-Topic: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd Thread-Index: AdUciY2y4WRjNep5RxiJQapQPwT8pgAMPUEAABlOi6A= Date: Fri, 7 Jun 2019 11:02:59 +0000 Message-ID: References: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="_000_bb2dff4230404b0c8845f0a78d943e3averisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 07 Jun 2019 11:03:04 -0000 --_000_bb2dff4230404b0c8845f0a78d943e3averisigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogZG1hcmMgPGRtYXJjLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDcmFpZyBT Y2h3YXJ0eg0KU2VudDogVGh1cnNkYXksIEp1bmUgNiwgMjAxOSAyOjUyIFBNDQpUbzogSG9sbGVu YmVjaywgU2NvdHQgPHNob2xsZW5iZWNrPTQwdmVyaXNpZ24uY29tQGRtYXJjLmlldGYub3JnPg0K Q2M6IGRtYXJjQGlldGYub3JnDQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbZG1hcmMtaWV0Zl0g UFNEcyBpbiBkcmFmdC1pZXRmLWRtYXJjLXBzZA0KDQoNCg0KDQoNCj5PbiBUaHVyc2RheSwgSnVu ZSA2LCAyMDE5IGF0IDE6MTIgUE0gRURUIFNjb3R0IEhvbGxlbmJlY2sgd3JvdGU6DQoNCj5JIHJl Y2VudGx5IGhhZCBhIGNoYW5jZSB0byByZWFkIHRocm91Z2ggZHJhZnQtaWV0Zi1kbWFyYy1wc2Qu IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHkgKGFuZCBJJ20gbm90IHN1cmUgdGhhdCBJIGRv KSwgdGhlIGRvY3VtZW50IHN1Z2dlc3RzIHRoYXQgaXQncyBwb3NzaWJsZSBmb3IgYSBUTEQgbGlr ZSAiLmNvbSIgPnRvIGJlIGEgUFNEIGFuZCBhIFRYVCByZWNvcmQgbGlrZSAiX2RtYXJjLmNvbTxo dHRwOi8vZG1hcmMuY29tLz4iIGNhbiBiZSBwdWJsaXNoZWQgaW4gdGhlIGNvbSB6b25lLiBJIGZv dW5kIHRoaXMgcGFydCBvZiB0aGUgZHJhZnQgY29uZnVzaW5nIGJlY2F1c2UgaXQncyBub3QgcG9z c2libGUgdG8gYWRkIFRYVCByZWNvcmRzIGxpa2UgdGhhdCA+dG8gdGhlIGNvbSB6b25lLiBJdCBt aWdodCBoZWxwIHRvIGV4cGxpY2l0bHkgbm90ZSBzb21ld2hlcmUgKHBlcmhhcHMgaW4gU2VjdGlv biAyLjIpIHRoYXQgdGhlcmUgbWF5IGJlIHBvbGljeSByZXN0cmljdGlvbnMgaW4gcGxhY2UgdGhh dCBkaXNhbGxvdyB0aGUgcHVibGljYXRpb24gb2YgRE1BUkMgcG9saWN5ID5yZWNvcmRzIGluIHNv bWUgRE5TIHpvbmVzLCBpbmNsdWRpbmcgc29tZSB0b3AtbGV2ZWwgZG9tYWluIHpvbmVzLg0KDQoN Cg0KDQpUaGUgcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQgaXMgdG8gY29udmV5IHRlY2huaWNhbGx5 IGhvdyBQU0QgRE1BUkMgY2FuIGJlIGFjY29tcGxpc2hlZCByYXRoZXIgdGhhbiB3aG8gY2FuIG9y IGNhbm5vdCB1bmRlcnRha2UgdGhpcyBkdWUgdG8gcG9saWN5IGNvbnNpZGVyYXRpb25zLiBBcyB0 aGUgb3BlcmF0b3Igb2YgLkJBTksgYW5kIC5JTlNVUkFOQ0UsIGZUTEQgaW5pdGlhdGVkIHRoaXMg c3RyZWFtIG9mIHdvcmsgd2l0aCB0aGUgSUVGVCBiZWNhdXNlIG9mIHRoZSBleHBsaWNpdCBwcm9o aWJpdGlvbiBieSBJQ0FOTiBmcm9tIGluc2VydGluZyBUWFQgcmVjb3JkcyBpbiB0aGUgRE5TLiBU aGUgZ29hbCBpcyB0byBnZXQgdG8gYW4gUkZDIHRoYXQgc3BlY2lmaWVzIHRoZSB0ZWNobmljYWwg YXNwZWN0IG9mIFBTRCBETUFSQyBhbmQgdWx0aW1hdGVseSBzZWVrIElDQU5OJ3MgYXBwcm92YWwg dG8gYWxsb3cgcHVibGljYXRpb24gb2Ygc3VjaCBhIHJlY29yZCBpbiB0aGUgRE5TLiBJbiBjb250 cmFzdCwgZ1RMRHMgbm90IHVuZGVyIGNvbnRyYWN0IHdpdGggSUNBTk4gc3VjaCBhcyAuTUlMIGFu ZCAuR09WLCB3aG8gYXJlIGJvdGggaW52b2x2ZWQgaW4gdGhpcyB3b3JrLCBkbyBub3QgaGF2ZSBh IGNvbnRyYWN0dWFsIHJlbGF0aW9uc2hpcCB3aXRoIElDQU5OIGFuZCB0aHVzIGFyZSBub3QgcHJv aGliaXRlZCBmcm9tIHRoaXMgYWN0aXZpdHksIGFuZCB0aGUgc2FtZSBnb2VzIGZvciBjY1RMRHMu DQoNCg0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHRoZSByZWFkZXIgaWYgdGhlIGRyYWZ0IHdl cmUgZWl0aGVyIGNsZWFyIGFib3V0IHBvdGVudGlhbCBsaW1pdGF0aW9ucyB0byBkZXBsb3ltZW50 IG9yIG1vcmUgZGVzY3JpcHRpdmUgYWJvdXQgdGhlIGRvbWFpbnMgZm9yIHdoaWNoIHRoZSBhcHBy b2FjaCBjYW4gd29yay4gUmlnaHQgbm93LCBQU0QgRE1BUkMgY2Fubm90IGJlIGRlcGxveWVkIHVi aXF1aXRvdXNseS4gVGhhdCByZWFsaXR5IHNob3VsZCBub3QgYmUgb3Zlcmxvb2tlZC4NCg0KDQoN ClNjb3R0DQoNCg== --_000_bb2dff4230404b0c8845f0a78d943e3averisigncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZG1hcmMgJmx0O2RtYXJjLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpDcmFpZyBTY2h3YXJ0ejxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgSnVuZSA2LCAyMDE5IDI6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IEhvbGxl bmJlY2ssIFNjb3R0ICZsdDtzaG9sbGVuYmVjaz00MHZlcmlzaWduLmNvbUBkbWFyYy5pZXRmLm9y ZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGRtYXJjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtFWFRFUk5BTF0gUmU6IFtkbWFyYy1pZXRmXSBQU0RzIGluIGRyYWZ0LWlldGYtZG1hcmMtcHNk PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7T24gVGh1cnNkYXksIEp1bmUgNiwgMjAxOSBhdCAxOjEyIFBNIEVEVCBTY290dCBI b2xsZW5iZWNrIHdyb3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O0kgcmVjZW50bHkgaGFkIGEgY2hhbmNlIHRvIHJl YWQgdGhyb3VnaCBkcmFmdC1pZXRmLWRtYXJjLXBzZC4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJl Y3RseSAoYW5kIEknbSBub3Qgc3VyZSB0aGF0IEkgZG8pLCB0aGUgZG9jdW1lbnQgc3VnZ2VzdHMg dGhhdCBpdCdzIHBvc3NpYmxlIGZvciBhIFRMRCBsaWtlICZxdW90Oy5jb20mcXVvdDsgJmd0O3Rv IGJlDQogYSBQU0QgYW5kIGEgVFhUIHJlY29yZCBsaWtlICZxdW90O188L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0i aHR0cDovL2RtYXJjLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZG1hcmMuY29tPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PiZxdW90OyBjYW4gYmUgcHVibGlzaGVkDQogaW4gdGhlIGNvbSB6b25lLiBJIGZvdW5kIHRoaXMg cGFydCBvZiB0aGUgZHJhZnQgY29uZnVzaW5nIGJlY2F1c2UgaXQncyBub3QgcG9zc2libGUgdG8g YWRkIFRYVCByZWNvcmRzIGxpa2UgdGhhdCAmZ3Q7dG8gdGhlIGNvbSB6b25lLiBJdCBtaWdodCBo ZWxwIHRvIGV4cGxpY2l0bHkgbm90ZSBzb21ld2hlcmUgKHBlcmhhcHMgaW4gU2VjdGlvbiAyLjIp IHRoYXQgdGhlcmUgbWF5IGJlIHBvbGljeSByZXN0cmljdGlvbnMgaW4gcGxhY2UgdGhhdCBkaXNh bGxvdw0KIHRoZSBwdWJsaWNhdGlvbiBvZiBETUFSQyBwb2xpY3kgJmd0O3JlY29yZHMgaW4gc29t ZSBETlMgem9uZXMsIGluY2x1ZGluZyBzb21lIHRvcC1sZXZlbCBkb21haW4gem9uZXMuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOzxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBwdXJwb3NlIG9m IHRoZSBkb2N1bWVudCBpcyB0byBjb252ZXkgdGVjaG5pY2FsbHkgaG93IFBTRCBETUFSQyBjYW4g YmUgYWNjb21wbGlzaGVkIHJhdGhlciB0aGFuIHdobyBjYW4gb3IgY2Fubm90IHVuZGVydGFrZSB0 aGlzIGR1ZSB0byBwb2xpY3kgY29uc2lkZXJhdGlvbnMuIEFzIHRoZSBvcGVyYXRvciBvZiAuQkFO SyBhbmQNCiAuSU5TVVJBTkNFLCBmVExEIGluaXRpYXRlZCB0aGlzIHN0cmVhbSBvZiB3b3JrIHdp dGggdGhlIElFRlQgYmVjYXVzZSBvZiB0aGUgZXhwbGljaXQgcHJvaGliaXRpb24gYnkgSUNBTk4g ZnJvbSBpbnNlcnRpbmcgVFhUIHJlY29yZHMgaW4gdGhlIEROUy4gVGhlIGdvYWwgaXMgdG8gZ2V0 IHRvIGFuIFJGQyB0aGF0IHNwZWNpZmllcyB0aGUgdGVjaG5pY2FsIGFzcGVjdCBvZiBQU0QgRE1B UkMgYW5kIHVsdGltYXRlbHkgc2VlayBJQ0FOTidzIGFwcHJvdmFsDQogdG8gYWxsb3cgcHVibGlj YXRpb24gb2Ygc3VjaCBhIHJlY29yZCBpbiB0aGUgRE5TLiBJbiBjb250cmFzdCwgZ1RMRHMgbm90 IHVuZGVyIGNvbnRyYWN0IHdpdGggSUNBTk4gc3VjaCBhcyAuTUlMIGFuZCAuR09WLCB3aG8gYXJl IGJvdGggaW52b2x2ZWQgaW4gdGhpcyB3b3JrLCBkbyBub3QgaGF2ZSBhIGNvbnRyYWN0dWFsIHJl bGF0aW9uc2hpcCB3aXRoIElDQU5OIGFuZCB0aHVzIGFyZSBub3QgcHJvaGliaXRlZCBmcm9tIHRo aXMgYWN0aXZpdHksDQogYW5kIHRoZSBzYW1lIGdvZXMgZm9yIGNjVExEcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5JdCB3b3VsZCBi ZSBoZWxwZnVsIHRvIHRoZSByZWFkZXIgaWYgdGhlIGRyYWZ0IHdlcmUgZWl0aGVyIGNsZWFyIGFi b3V0IHBvdGVudGlhbCBsaW1pdGF0aW9ucyB0byBkZXBsb3ltZW50IG9yIG1vcmUgZGVzY3JpcHRp dmUgYWJvdXQgdGhlIGRvbWFpbnMgZm9yIHdoaWNoIHRoZSBhcHByb2FjaCBjYW4gd29yay4gUmln aHQgbm93LCBQU0QgRE1BUkMgY2Fubm90IGJlIGRlcGxveWVkIHViaXF1aXRvdXNseS4NCiBUaGF0 IHJlYWxpdHkgc2hvdWxkIG5vdCBiZSBvdmVybG9va2VkLjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNjb3R0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_bb2dff4230404b0c8845f0a78d943e3averisigncom_-- From btv1==061bcd72c02==fosterd@bayviewphysicians.com Fri Jun 7 16:03:31 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A19120161 for ; Fri, 7 Jun 2019 16:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 lho--RZYfRlN for ; Fri, 7 Jun 2019 16:03:30 -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 CE04112002E for ; Fri, 7 Jun 2019 16:03:29 -0700 (PDT) X-ASG-Debug-ID: 1559948608-11fa3116c8398a00001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id g4yjSCckCDSCssA1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 07 Jun 2019 19:03:28 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client 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=7DI8lWgd++bjabQ+IWFbppyQMCPwDKcNT/BchJ9Jds0=; b=efIkIMlX++PW0qYYNI7gx4wjCW4M4zJAsrHnxzoBC+PE6MVM/oitaijy4N2utMfmj oM52LRHzgFz56YwcAXPS+cT8hLd+G8ho6QyquW9w1dQKya94sMFdYnAP9QeW0C0zp i1PCJLxhVu/GAXfC6RQWa5hhZyzTnUOaF/fY6fZAQ= Received: by webmail.bayviewphysicians.com via HTTP; Fri, 7 Jun 2019 19:03:19 -0400 From: "Douglas E. Foster" To: "John R Levine" , , Date: Fri, 7 Jun 2019 19:03:19 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Endless Loops with DKIM reports Reply-To: fosterd@bayviewphysicians.com Message-ID: <1f3e445b735945369d93ce594c8fae65@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=d5143100ad0d4d6f9ad9e4109933956b X-Originating-IP: [192.168.1.239] In-Reply-To: References: <20190605200619.2ED512014FE9B7@ary.local> <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> X-Exim-Id: 1f3e445b735945369d93ce594c8fae65 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1559948608 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: 5950 X-Barracuda-BRTS-Status: 0 Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 23:06:34 -0000 This is a multipart message in MIME format. --d5143100ad0d4d6f9ad9e4109933956b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Suggestions for eliminating loops: Best (sender controlled) The report-sending account should be from a non-reportable domain or subdomain. Authority to report on behalf of another domain/sub-domain can be established with a DKIM signature of the reporting domain. Of course, if the report-sending domain is a subdomain of a reportable domain, the sub-domain needs its own DMARC policy to disable inheritance and to disable reporting. The report-sending account could be placed in a domain/sub-domain which is send-only (SPF policy but no MX records). This prevents out-of-office messages, NDRs, or spam from being sent to the report-sending account. A null sender would be one way of producing this result, but it may be difficult to implement in some configurations. Additionally, messages from the null sender are more likely to be rejected by BATV filtering. Alternate (sender controlled) If the report-sending account is in a domain/sub-domain that collects feedback, messages sent to the report-sending account must be excluded from feedback data collection. Backup (recipient controlled) Option 1: The recipient account should be in a domain/subdomain that does not collect DMARC feedback. Option 2: If the recipient account domain does collect feedback data, the recipient account must be excluded from feedback data collection. Since the sender cannot know whether the recipient domain collects DMARC feedback, he should not rely on the sender being able to prevent looping. I think these methods will eliminate the need for rate limiting. Doug Foster ---------------------------------------- From: "Dave Crocker" Sent: Thursday, June 6, 2019 4:28 AM To: "John R Levine" , dmarc@ietf.org Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports On 6/6/2019 10:08 AM, John R Levine wrote: > If people follow the spec there will be fewer loops, but it won't reduce > the number to zero. Forgive me, but I believe there is currently no spec to follow. Yet. I took this thread as raising the issue that there needs to be an effort that specifies how to avoid dmarc report loops. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --d5143100ad0d4d6f9ad9e4109933956b Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
Suggestions for eliminating loops:
 
Best (sender controlled)
The report-sending account should be from a non-reportable domain or s= ubdomain.   Authority to report on behalf of another domain/sub-d= omain can be established with a DKIM signature of the reporting domain.&nbs= p;  Of course, if the report-sending domain is a subdomain of a report= able domain, the sub-domain needs its own DMARC policy to disable inheritan= ce and to disable reporting.
 
The report-sending account could be placed in a domain/sub-domain whic= h is send-only (SPF policy but no MX records).   This preven= ts out-of-office messages, NDRs, or spam from being sent to the report= -sending account. 
 
A null sender would be one way of producing this result, but it may be= difficult to implement in some configurations.   Additionally, m= essages from the null sender are more likely to be rejected by BATV fi= ltering.
 
Alternate (sender controlled)
If the report-sending account is in a domain/sub-domain that coll= ects feedback, messages sent to the report-sending account must b= e excluded from feedback data collection.
 
 
Backup (recipient controlled)
Option 1:  The recipient account should be in a domain/subdo= main that does not collect DMARC feedback.
Option 2:  If the recipient account domain does collect feedback = data, the recipient account must be excluded from feedback data collec= tion.
 
Since the sender cannot know whether the recipient domain co= llects DMARC feedback, he should not rely on the sender being able to preve= nt looping.
 
I think these methods will eliminate the need for rate limiting.
 
Doug Foster
 
 
From: "Dave Crocker" <dhc@dcrocker.net>
Sent: Thursday, June 6, 2019 4:28 AM
To: "John R Levine" <johnl@taugh.com>, dmarc@ietf.or= g
Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports
 
On 6/6/2019 10:08 AM, John R Levine wrote:
> If people follow the spec there will be fewer loops, but it won't redu= ce
> the number to zero.

Forgive me, but I believe there is currently no spec to follow. Yet. I
took this thread as raising the issue that there needs to be an effort
that specifies how to avoid dmarc report loops.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
 
 --d5143100ad0d4d6f9ad9e4109933956b-- From nobody Sat Jun 8 07:56:14 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6458A1200A3 for ; Sat, 8 Jun 2019 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=OJTUmD15; dkim=pass (1536-bit key) header.d=taugh.com header.b=Bh2a8um/ 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 Dx9z5hsPTkkA for ; Sat, 8 Jun 2019 07:56:10 -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 9408612008F for ; Sat, 8 Jun 2019 07:56:10 -0700 (PDT) Received: (qmail 6117 invoked from network); 8 Jun 2019 14:56:08 -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=17e3.5cfbcc88.k1906; i=johnl-iecc.com@submit.iecc.com; bh=FXtzghrfg5xbyYUKHx+Mc63j6a3eIhk0KM1vEd6KvAY=; b=OJTUmD15lPC4S7v5KjeM7KQazD/U533XIGJlyAzLO18vjEEUgy659DjdRrI86/PoB+ouOqSLdIkspLefqqLbdusA8VInYMknuKFBmbQP0rzmQZLHvsmKZSNYufaeOqTI9sIeqlntyRXZ4XppWqVNxTTz7AQlPuwu1JT6KE3my2QOjZXpN0aSv1ndNcj0Jce5dB/LCL5oqyNvt3YNu0MHsiZIAmDXGtC1U2SglX6TNd440DXyQRs1HiAyGP3AvX53 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=17e3.5cfbcc88.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=FXtzghrfg5xbyYUKHx+Mc63j6a3eIhk0KM1vEd6KvAY=; b=Bh2a8um/3g05XN0ZfeOhKNHyOdbPdBKM1p7lTBalvO3dTwf1cpUj1YV+ECqJc+1q/C68YveZo80J7x8mIaJhmw7ew6kXQ7gOfzMfXDFH5I1LZpzaBHaVLHzTE5URjgoQVVn/IAY7nWfRtjHS/gQbClhtfSL+CsgONuvnTl4aZFm0fmI7CFlvkZaFvvuzuF+r23XaS6shRD7Ae+803sE0UiDFPjT3ekKOxDL4cwmGXnuLszqCTCvgLofSyIjjqnRQ 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.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 08 Jun 2019 14:56:08 -0000 Date: 8 Jun 2019 16:56:08 +0200 Message-ID: From: "John R Levine" To: "Douglas E. Foster" Cc: dmarc@ietf.org In-Reply-To: <1f3e445b735945369d93ce594c8fae65@bayviewphysicians.com> References: <20190605200619.2ED512014FE9B7@ary.local> <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> <1f3e445b735945369d93ce594c8fae65@bayviewphysicians.com> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 14:56:13 -0000 On Fri, 7 Jun 2019, Douglas E. Foster wrote: > Suggestions for eliminating loops: ... These are all fine. > I think these methods will eliminate the need for rate limiting. BTDT. Really, I have been doing various forms of autoresponders for thirty years, and no matter what you do, someone will loop back anyway, most likely from an address different from the one you sent the report to. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 8 09:49:16 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23648120123 for ; Sat, 8 Jun 2019 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 TNJgr5YkRtDb for ; Sat, 8 Jun 2019 09:49:12 -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 89F2412011B for ; Sat, 8 Jun 2019 09:49:12 -0700 (PDT) Received: from [10.97.137.43] ([149.137.255.211]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x58GpJT4006023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Jun 2019 09:51:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1560012679; bh=Z2diibYa5SvmTLJI1m1ZWqnaRV2cl2mXRwb3X7R0kro=; h=From:Subject:To:References:Cc:Reply-To:Date:In-Reply-To:From; b=fMmYvIScJSTNuHuHXgmTkCKvPr53ZCJjg/AiXAxtmtCLM7RL0gpdXlW+iE5g4l7Bs Qb7qdZq3nP4a4Mz9gfOnbBfDwOZY9EuVm1I3t86La73LTLAwk/DsdZ7LfjoKNioubb SCsUKV1xhGqw6QBl2JG23hrbJdSk+0WrIQ5SGe5Y= From: Dave Crocker To: fosterd@bayviewphysicians.com References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> Cc: dmarc@ietf.org Reply-To: dcrocker@bbiw.net Message-ID: <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> Date: Sat, 8 Jun 2019 09:49:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <941abdbf28684283b972f69f25876220@bayviewphysicians.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Mandatory Sender Authentication 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, 08 Jun 2019 16:49:15 -0000 On 6/6/2019 7:09 PM, Douglas E. Foster wrote: >>> 1. By 'sender', which actor in the sequence do you mean? The term is > highly ambiguous. > By Sender Authentication, I mean message "From Address" authentication. > This involves two rules: > > * The sending IP address is known to be authorized to send for the > SMTP Sender-Address because of MXor SPF, and MX does not 'authorize' sending by an IP address, although some receivers do check for MX as a heuristic. But a heuristic is outside of any 'standard'. SPF does register IP to domain name for sending. > * the SMTP Sender-Address is known to be authorized to send for the Sorry, but the term "SMTP Sender-Address" does not have any specified or reliable meaning. > message from Address because of either > o domain alignment or > o a verifiable DKIM signature for the domain of the message > From-Address. > > The message From-Address is what the user sees, so it seems important to > know that the user is not being deceived by an impersonator. I assume you mean the RFC5322-level From: field, as opposed to the RFC5321-level Mail From command. Except that most users don't actually see that address because these days most MUAs only display the display address. As for end users being deceived, there's quite a bit of experience that showing users indicators doesn't alter their behavior. >>> 2. Your certitude presumes an empirical foundation, given how often good > theory does not make good practice. People have been working in this > space for a very long time and one might have expected the industry to > have latched on such a simple requirement were it that clear it was > /the/ essential requirement. Please document the basis for your certitude. > What I actually intend is that "a recipient has a viable option to > implement mandatory sender authentication." I don't understand what it means to have an option to implement something that is mandatory. It's mandatory. Also by saying 'recipient' rather than 'receiver' you appear to be indicating the end users will do meaningful filtering based on this kind of information. They won't. > This i equivalent to enforcing basic DMARC rules whether the sender has > a DMARC policy or not. This requires: That means you are seeking to alter fundamental email semantics by fiat, globally. Surely you jest. >>> 4. Consider the limitations to 'sender' authentication. > > I am spending a lot of time thinking about the limitations of sender > authentication. For a spammer domain, SPF / DKIM / DMARC are easy. What do you mean? > For impersonation, Friendly Name and embedded logo images can be > pretty effective without violating SPF / DKIM / DMARC. That's correct. And there has been extensive discussions looking to do something about that but there are no proposals on the table, because so far none has looked viable. > This means that Sender Authentication may produce more false positives No it doesn't. The existing authentication mechanisms do a good job of authenticating what they are authenticating. It appears that you are seeking to use the information far beyond what is valid. > Tominimize false positives, I would like to see: > > * Pressure on list forwarders to either not break signatures, or > follow the IETF example of replacing the original from with the list > domain and signing the new message with the list domain. You want to bring pressure on list processing developers and/or operators. Good luck with that. > * Advice to senders to reduce signature complexity. In the general What does that mean? What specific proposal do you have? > mail stream, the purpose of the DKIM signature is to authenticate You appear to misunderstand the semantics of DKIM. Please re-read its specification and supporting document, because they have simple, concise language about what it does. > But I have already been told that IETF is not interested in Recipient > product problems, and is not concerned with security, which has left me > very disappointed. I suspect you have been told nothing of the sort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 10 01:17:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225A4120132 for ; Mon, 10 Jun 2019 01:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHB139i4eqbs for ; Mon, 10 Jun 2019 01:17:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D96F120118 for ; Mon, 10 Jun 2019 01:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560154665; bh=nhGnSSpLXxIQl8QX31Bz1GWScj/mWtq9zykA/xvWlrc=; l=614; h=To:References:From:Date:In-Reply-To; b=BSk8IPbBAMRF0+ZDWjc16U5mHY/216UQpOw8cCvn/EsbcfZyuLez9EHonu/zIV0kX 5rR7tK+/61+ApWEQWPOJB0LIs3HV6Ms6yVTOjsT9pqrnt/EuoUsaO7L2UvGeRcW+XQ jISnZ1IM0F7C4RjGyQIEyPNfGstu8x+S8fyssuGJ9jIMheWHkaSMX/iuOVdl/ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 10 Jun 2019 10:17:45 +0200 id 00000000005DC077.000000005CFE1229.0000432E To: dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> Date: Mon, 10 Jun 2019 10:17:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 10 Jun 2019 08:17:49 -0000 On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: > Except that most users don't actually see that address because these days most > MUAs only display the display address. We often came across this realization. Since DMARC hinges on that field, I think the spec should include some advice to MUA implementation. A trust on first use (TOFU) approach would seem to be possible. On getting the same display name linked to a different domain part, a user would be required to configure the MUA's behavior for this particular name / domain. Does this subject deserve a ticket? Best Ale -- From nobody Mon Jun 10 05:07:31 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EA1120180 for ; Mon, 10 Jun 2019 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvsQSsL_zxiM for ; Mon, 10 Jun 2019 05:07:28 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100118.outbound.protection.outlook.com [40.107.10.118]) (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 3F46012017D for ; Mon, 10 Jun 2019 05:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UldEwmdC5yOEeMEvVeHB9B/d+SpX55II9vpEhiytGuQ=; b=CPYPdJFZWOyK+irKAYR9acWv5OBBSi+8YGC3M4BDE6vSu+U6LtVavjgWl0TKg+tBB1t/nxKNDus/IuectoPFCa8+oNcgjffEdz08HuMVhOeLPCKMsEKDX7D01jMUujBVS7NXbe0oKbsiR2o2pvnvBwSPo0FirZYzIxbL6z1dHSM= Received: from LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM (20.176.156.23) by LO2P123MB1854.GBRP123.PROD.OUTLOOK.COM (20.176.154.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.15; Mon, 10 Jun 2019 12:07:25 +0000 Received: from LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM ([fe80::fc74:1f4:86dc:24de]) by LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM ([fe80::fc74:1f4:86dc:24de%7]) with mapi id 15.20.1965.017; Mon, 10 Jun 2019 12:07:25 +0000 From: Richard C To: Seth Blank CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] DMARC PSD and non-existent subdomains Thread-Index: AdUW/jphmQ6IwLIpSlOVp/KM9LEwVAAQ0CMAAOBoajA= Date: Mon, 10 Jun 2019 12:07:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Richard.C@ncsc.gov.uk; x-originating-ip: [51.141.34.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 230802dc-707e-4212-b759-08d6ed9c33b4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB1854; x-ms-traffictypediagnostic: LO2P123MB1854: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(39850400004)(396003)(366004)(189003)(51914003)(199004)(66556008)(66476007)(66946007)(66446008)(8936002)(68736007)(26005)(5660300002)(71200400001)(476003)(66066001)(186003)(64756008)(76116006)(7736002)(14444005)(256004)(25786009)(6916009)(76176011)(102836004)(73956011)(6116002)(3846002)(7696005)(11346002)(446003)(6506007)(55236004)(4326008)(790700001)(53936002)(478600001)(74316002)(52536014)(75922002)(316002)(99286004)(606006)(14454004)(33656002)(6246003)(72206003)(74482002)(55016002)(54896002)(6306002)(236005)(81156014)(6436002)(8676002)(71190400001)(81166006)(86362001)(229853002)(486006)(2906002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB1854; H:LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4GJ1ngpDycx/SRhJPsdPhwL+iLlnR1LCMDGuoM8lUl2aMVT6yJZwGA4HA+6gNbFeiUNhm32B9FzHie82g3v+yr1l5XmVvKClBTIrRaoGPt4ktTO0YX/LlKEzmOtkbWHNsaCXhtb1GXqkyjJ4rSpHnfR3BostzFHPXfyPfgl0D68hN1T5hWD80hxoyjrbGmPqw+i3bLq24NzQ4ll+evPenKPgN1fw8cWXLRuNmaS5zWQdw32Tm2rnX+pCzveUoj04yrYcvxdUybOfIkkB/8Femh72P7vpb+N58SVeKKF5kR1rh3ArjZrUjUvx+tmplmtK49ApRaoeyZ8XLLPxi1z6WDK2U2yhPxbiat9WwRHkDI6lr75usdiXSpR1YRU1gc9LqE+26pLAq2hn1vNEpKn4DHAqiqp2fAx2UYGTIY6wNL8= Content-Type: multipart/alternative; boundary="_000_LO2P123MB23346502F9B6F1EE38269147AD130LO2P123MB2334GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 230802dc-707e-4212-b759-08d6ed9c33b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2019 12:07:25.6007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: richard49955@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1854 Archived-At: Subject: Re: [dmarc-ietf] DMARC PSD and non-existent subdomains 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, 10 Jun 2019 12:07:30 -0000 --_000_LO2P123MB23346502F9B6F1EE38269147AD130LO2P123MB2334GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcXVlc3Rpb24sIFNldGguDQpXaGF0IHdvdWxkIGJlIHRoZSBiZXN0IHdh eSB0byBpbmNvcnBvcmF0ZSB0aGlzIHJlcXVpcmVtZW50Pw0KVGhlIHNpbXBsZXN0IHBvc3NpYmxl IHdheSB0byBhZGRyZXNzIHRoaXMgdXNlIGNhc2UgaXMganVzdCB0byBtYWtlIHN1cmUgdGhvc2Ug ZXhpc3RpbmcgYnV0IGN1cnJlbnRseSBub24tY29tcGxpYW50IGRvbWFpbnMganVzdCBoYXZlIGEg YmFyZSBwPW5vbmUgcmVjb3JkLiBUaGVuIHRoZXknbGwgbmV2ZXIgZmFsbCBiYWNrIHRvIHRoZSBn b3YudWs8aHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHAlM0ElMkYlMkZnb3YudWsmZGF0YT0wMiU3QzAxJTdDUmljaGFyZC5DJTQwbmNzYy5nb3Yu dWslN0M1ZTQwNGI0NDYzM2Y0ZjYyNTc2YzA4ZDZlNTU4YjM1MyU3QzE0YWE1NzQ0ZWNlMTQ3NGVh MmQ3MzRmNDZkZGE2NGExJTdDMCU3QzAlN0M2MzY5NDg1NjY0NjA2NzIwMTQmc2RhdGE9aWhmNHNv TWE4a1IlMkJjR0Z3amlJd2d5OWlIRG5ybktMa2F3c2owWm05TWk0JTNEJnJlc2VydmVkPTA+IHJl Y29yZC4gVGhlcmUncyBubyByaXNrIHRvIGluYWR2ZXJ0ZW50bHkgYnJlYWtpbmcgbWFpbCBoZXJl Lg0KDQpJcyBpdCByZW1vdGVseSByZWFsaXN0aWMgZm9yIHlvdSB0byBvZmZlciB0aGlzIGd1aWRh bmNlPyBJZiB5b3UncmUgYWxyZWFkeSBzYXlpbmcgdGhhdCBwPXJlamVjdCBpcyByZXF1aXJlZCwg aG93IHBhaW5mdWwgaXMgaXQgdG8gYWR2ZXJ0aXNlIHRoYXQgYW55IGRvbWFpbiB3aXRob3V0IGEg RE1BUkMgcmVjb3JkIHdpbGwgZ2V0IHA9cmVqZWN0IGJ5IGRlZmF1bHQgdW5sZXNzIGl0IGV4cGxp Y2l0bHkgcHV0cyBwPW5vbmUgaW4/DQoNCkkgd2lzaCB0aGF0IHB1Ymxpc2hpbmcgZ3VpZGFuY2Ug cmVzdWx0ZWQgaW4gc3dpZnQgYWRvcHRpb24gb2YgaXQgYnV0IHVuZm9ydHVuYXRlbHkgaXTigJlz IG5vdCBzbyBzaW1wbGUuIFdlIGFscmVhZHkgaGF2ZSBndWlkYW5jZSBwdWJsaXNoZWQgcmVxdWVz dGluZyB0aGF0IG9yZ2FuaXNhdGlvbnMgY29uZmlndXJlIERNQVJDIG9uIHRoZWlyIGdvdi51ayBk b21haW4gKHN0YXJ0aW5nIGF0IOKAmG5vbmXigJkgYW5kIHByb2dyZXNzaW5nIHRvIOKAmHJlamVj dOKAmSBhcyB0aGV5IGdhaW4gY29uZmlkZW5jZSkuIFRoZSBwcm9ibGVtIGlzIHdlIGhhdmUgfjM1 MDAgZG9tYWlucyBpbiB1c2UsIG1hbnkgYnkgc21hbGxlciBvcmdhbmlzYXRpb25zIHdpdGggbGlt aXRlZCB0ZWNobmljYWwgYWJpbGl0eS4gV2hpbHN0IHdl4oCZbGwgY29udGludWUgdG8gd29yayB0 b3dhcmRzIGhlbHBpbmcgdGhlbSBhbGwgZGVwbG95IERNQVJDLCByZWFsaXN0aWNhbGx5IHRoZXJl IHdpbGwgYmUgYSBsb25nIHRhaWwgdG8gYWRvcHRpb24sIGhlbmNlIG91ciBpbnRlcmVzdCBpbiBz dXBwb3J0IGZvciBkaWZmZXJlbnQgcG9saWNpZXMgZm9yIHRoZSBleGlzdGVudCBhbmQgbm9uLWV4 aXN0ZW50IHN1YmRvbWFpbnMgaW4gRE1BUkMgUFNELg0KDQpQcmVzdW1hYmx5IG90aGVyIFBTRHMg dGhhdCBhcmVu4oCZdCBicmFuZCBuZXcgd2lsbCBoYXZlIHRoaXMgcHJvYmxlbSB0b28/IEnigJlt IGludGVyZXN0ZWQgdG8gaGVhciB3aGV0aGVyIHdl4oCZcmUgb24gb3VyIG93biBvciBub3QuDQoN ClJpY2hhcmQNClRoaXMgaW5mb3JtYXRpb24gaXMgZXhlbXB0IHVuZGVyIHRoZSBGcmVlZG9tIG9m IEluZm9ybWF0aW9uIEFjdCAyMDAwIChGT0lBKSBhbmQgbWF5IGJlIGV4ZW1wdCB1bmRlciBvdGhl ciBVSyBpbmZvcm1hdGlvbiBsZWdpc2xhdGlvbi4gUmVmZXIgYW55IEZPSUEgcXVlcmllcyB0byBu Y3NjaW5mb2xlZ0BuY3NjLmdvdi51aw0K --_000_LO2P123MB23346502F9B6F1EE38269147AD130LO2P123MB2334GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgZm9yIHRoZSBxdWVzdGlvbiwgU2V0aC4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQgd291bGQgYmUgdGhlIGJlc3Qg d2F5IHRvIGluY29ycG9yYXRlIHRoaXMgcmVxdWlyZW1lbnQ/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBzaW1wbGVzdCBwb3NzaWJsZSB3YXkgdG8gYWRkcmVzcyB0aGlzIHVzZSBjYXNlIGlzIGp1c3Qg dG8gbWFrZSBzdXJlIHRob3NlIGV4aXN0aW5nIGJ1dCBjdXJyZW50bHkgbm9uLWNvbXBsaWFudCBk b21haW5zIGp1c3QgaGF2ZSBhIGJhcmUgcD1ub25lIHJlY29yZC4gVGhlbiB0aGV5J2xsIG5ldmVy IGZhbGwgYmFjayB0byB0aGUNCjxhIGhyZWY9Imh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZ292LnVrJmFtcDtkYXRhPTAyJTdD MDElN0NSaWNoYXJkLkMlNDBuY3NjLmdvdi51ayU3QzVlNDA0YjQ0NjMzZjRmNjI1NzZjMDhkNmU1 NThiMzUzJTdDMTRhYTU3NDRlY2UxNDc0ZWEyZDczNGY0NmRkYTY0YTElN0MwJTdDMCU3QzYzNjk0 ODU2NjQ2MDY3MjAxNCZhbXA7c2RhdGE9aWhmNHNvTWE4a1IlMkJjR0Z3amlJd2d5OWlIRG5ybktM a2F3c2owWm05TWk0JTNEJmFtcDtyZXNlcnZlZD0wIj4NCmdvdi51azwvYT4gcmVjb3JkLiBUaGVy ZSdzIG5vIHJpc2sgdG8gaW5hZHZlcnRlbnRseSBicmVha2luZyBtYWlsIGhlcmUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0IHJlbW90 ZWx5IHJlYWxpc3RpYyBmb3IgeW91IHRvIG9mZmVyIHRoaXMgZ3VpZGFuY2U/IElmIHlvdSdyZSBh bHJlYWR5IHNheWluZyB0aGF0IHA9cmVqZWN0IGlzIHJlcXVpcmVkLCBob3cgcGFpbmZ1bCBpcyBp dCB0byBhZHZlcnRpc2UgdGhhdCBhbnkgZG9tYWluIHdpdGhvdXQgYSBETUFSQyByZWNvcmQgd2ls bCBnZXQgcD1yZWplY3QgYnkgZGVmYXVsdCB1bmxlc3MgaXQgZXhwbGljaXRseSBwdXRzIHA9bm9u ZQ0KIGluPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd2lzaCB0aGF0IHB1Ymxpc2hpbmcgZ3VpZGFuY2UgcmVzdWx0ZWQgaW4gc3dpZnQg YWRvcHRpb24gb2YgaXQgYnV0IHVuZm9ydHVuYXRlbHkgaXTigJlzIG5vdCBzbyBzaW1wbGUuIFdl IGFscmVhZHkgaGF2ZSBndWlkYW5jZSBwdWJsaXNoZWQgcmVxdWVzdGluZyB0aGF0IG9yZ2FuaXNh dGlvbnMgY29uZmlndXJlIERNQVJDIG9uIHRoZWlyIGdvdi51ayBkb21haW4gKHN0YXJ0aW5nIGF0 IOKAmG5vbmXigJkgYW5kIHByb2dyZXNzaW5nDQogdG8g4oCYcmVqZWN04oCZIGFzIHRoZXkgZ2Fp biBjb25maWRlbmNlKS4gVGhlIHByb2JsZW0gaXMgd2UgaGF2ZSB+MzUwMCBkb21haW5zIGluIHVz ZSwgbWFueSBieSBzbWFsbGVyIG9yZ2FuaXNhdGlvbnMgd2l0aCBsaW1pdGVkIHRlY2huaWNhbCBh YmlsaXR5LiBXaGlsc3Qgd2XigJlsbCBjb250aW51ZSB0byB3b3JrIHRvd2FyZHMgaGVscGluZyB0 aGVtIGFsbCBkZXBsb3kgRE1BUkMsIHJlYWxpc3RpY2FsbHkgdGhlcmUgd2lsbCBiZSBhIGxvbmcg dGFpbCB0bw0KIGFkb3B0aW9uLCBoZW5jZSBvdXIgaW50ZXJlc3QgaW4gc3VwcG9ydCBmb3IgZGlm ZmVyZW50IHBvbGljaWVzIGZvciB0aGUgZXhpc3RlbnQgYW5kIG5vbi1leGlzdGVudCBzdWJkb21h aW5zIGluIERNQVJDIFBTRC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJlc3VtYWJseSBvdGhl ciBQU0RzIHRoYXQgYXJlbuKAmXQgYnJhbmQgbmV3IHdpbGwgaGF2ZSB0aGlzIHByb2JsZW0gdG9v PyBJ4oCZbSBpbnRlcmVzdGVkIHRvIGhlYXIgd2hldGhlciB3ZeKAmXJlIG9uIG91ciBvd24gb3Ig bm90LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWNoYXJkPG86cD48L286cD48L3A+DQo8L2Rp dj4NClRoaXMgaW5mb3JtYXRpb24gaXMgZXhlbXB0IHVuZGVyIHRoZSBGcmVlZG9tIG9mIEluZm9y bWF0aW9uIEFjdCAyMDAwIChGT0lBKSBhbmQgbWF5IGJlIGV4ZW1wdCB1bmRlciBvdGhlciBVSyBp bmZvcm1hdGlvbiBsZWdpc2xhdGlvbi4gUmVmZXIgYW55IEZPSUEgcXVlcmllcyB0byBuY3NjaW5m b2xlZ0BuY3NjLmdvdi51aw0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_LO2P123MB23346502F9B6F1EE38269147AD130LO2P123MB2334GBRP_-- From nobody Mon Jun 10 12:23:38 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D01A1200E9 for ; Mon, 10 Jun 2019 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=KoSLcw0l; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=QPNcN0v5 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 zaRJz-pWaGBY for ; Mon, 10 Jun 2019 12:23:34 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5617312007A for ; Mon, 10 Jun 2019 12:23:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1982; t=1560194607; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=V8VRgK0Cm/euUaDqxk5lRLX262Q=; b=KoSLcw0lAYb6crEvH4wjojtf4rRXyRGW5J6e7TTtp+TYBTjYJPcsg/DYq9k5zQ dCYOSeuprpi4oKXwLYtzR/znIwNU4WZABM1nvahNCgJzMoUz0QeG0XwBdUomFvq9 zjgjUAKJTxsH/CBv0PBXxq36uWVLIN9cS5+h5MnP+p/PI= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Mon, 10 Jun 2019 15:23:27 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 987047889.1.4508; Mon, 10 Jun 2019 15:23:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1982; t=1560194412; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bJ4g3DX uFyS6jug/pnhCDIMPtT475Vb27OglYnJ1h7A=; b=QPNcN0v5A+yfRonk4C/NzT4 qt8dd3IgWlP7q+2PxgLgd9TS6KQD5wvWd6qly4OhwXTJeU58jQtOyE9neivt3EIl bjuM0X2yufX1DXLpGnRza+qjOIunsqmSMVUcj/bKoZjzfeleN5Kw3gN7iCZDwdeJ A07c2DRaX5pY+mcV8r/M= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Mon, 10 Jun 2019 15:20:12 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2559267754.9.348464; Mon, 10 Jun 2019 15:20:11 -0400 Message-ID: <5CFEAE2E.90308@isdg.net> Date: Mon, 10 Jun 2019 15:23:26 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> In-Reply-To: <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 10 Jun 2019 19:23:37 -0000 On 6/10/2019 4:17 AM, Alessandro Vesely wrote: > On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: > >> Except that most users don't actually see that address because these days most >> MUAs only display the display address. > > > We often came across this realization. Since DMARC hinges on that field, I > think the spec should include some advice to MUA implementation. > > A trust on first use (TOFU) approach would seem to be possible. On getting the > same display name linked to a different domain part, a user would be required > to configure the MUA's behavior for this particular name / domain. > > Does this subject deserve a ticket? > Don't you think we might repeat and come to the same conclusions regarding MUA considerations in this regard? The primary concern would be 5322.From "Display" spoofing with the theoretical Multiple 5322.From headers potential exploit. A 2010 proof of concept list message example was showed it was possible to contain a valid DKIM signature and with a spoofed From display from "President Obama:" http://mipassoc.org/pipermail/ietf-dkim/2010q4/014680.html This created a long threaded discussion, and if I recall, the topic was repeated a few years later where I believe we had a consensus this was a "RFC5322 Boundary Layer" issue where the MSA/MDA or the backend would be better at handling the RFC5322 "validity" of an inbound message. It would be a good idea for receivers to do RFC5322 checking anyway instead of "passing the buck" to the many different MUA vendors including the many legacy MUAs people still enjoy today. If any protocol guidance is necessary here, IMO, it would be to repeat the suggestion for RFC5322 validity/security checks SHOULD be done at the backend to better protect the MUA end users using different Offline, Online and Hybrids models of MUAs. An inbound message with multiple 5322.From headers SHOULD be invalided, rejected or discarded. -- HLS From nobody Mon Jun 10 13:17:08 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA80B1200B9 for ; Mon, 10 Jun 2019 13:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 tKEqyv8T7dOT for ; Mon, 10 Jun 2019 13:17:05 -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 04B1A12003E for ; Mon, 10 Jun 2019 13:17:04 -0700 (PDT) Received: from [192.168.1.87] (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 x5AKJEYa024483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Jun 2019 13:19:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1560197955; bh=dwmbmt+ayjyzeWwxhoNY9dgT0qcSoAFXg8nmsPcyK3E=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=hm5GRspwN4hSfxzvCnmVLgp3N6PTPOfE00slqBjq18ZlaeA4OMsXBE7e7q2TPjObS eeXni/JftLuqRGiTcxr4IEhblY2MP4ynE+u5I78o8HX87paRAdofQRGcNgqtFlqetd nQtljR//uIzhcUpntnO5MyfFcrXPwKsEZR2B+zdY= To: Alessandro Vesely , dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Message-ID: <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> Date: Mon, 10 Jun 2019 13:17:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 10 Jun 2019 20:17:07 -0000 On 6/10/2019 1:17 AM, Alessandro Vesely wrote: > On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: > >> Except that most users don't actually see that address because these days most >> MUAs only display the display address. > > > We often came across this realization. Since DMARC hinges on that field, I > think the spec should include some advice to MUA implementation. Unfortunately there is no 'advice' to give that has any utility. If you feel otherwise, please try to formulate it, including the basis for believing it useful, and then try to get community support for it. > A trust on first use (TOFU) approach would seem to be possible. In practical terms, what does that mean? Who does what, exactly? What is the basis for believing anyone will actually do it? > On getting the > same display name linked to a different domain part, a user would be required > to configure the MUA's behavior for this particular name / domain. Specifying user behavior is both outside the usual scope of IETF work and a task with frustratingly poor utility. > Does this subject deserve a ticket? Since it has nothing to do with errors or problems with the current spec, I don't see how to justify a ticket. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 10 15:26:18 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA7112006E for ; Mon, 10 Jun 2019 15:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ebIGibBt; dkim=pass (2048-bit key) header.d=kitterman.com header.b=QAeLOGM9 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 NEnPI7GVIHmb for ; Mon, 10 Jun 2019 15:26:14 -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 ADF2A120025 for ; Mon, 10 Jun 2019 15:26:14 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id A6355F807AB for ; Mon, 10 Jun 2019 18:26: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=1560205573; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=w/MNzqVlc2DfyU+8CFSNlveb1mrqXlRefxQiII2J4jc=; b=ebIGibBt8aWxYvNOKdk3wcAhe3fxUw+dtcQSifvCK6eddaianNJuLa/F HfFi2HRc50M1ThKn6PHInAJ0HjKABw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1560205573; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=w/MNzqVlc2DfyU+8CFSNlveb1mrqXlRefxQiII2J4jc=; b=QAeLOGM92vWF/vWOveEy7N8KXne15dbFHzyHt6VX0DROu3G7X20cAxm3 B20Zbau513a+jNv8qwTFO2qe/M5e2sf+cWkX0aF3BPcwUWRz5c19iErFae 6toWWcQzW9Gm5OLAo1+smKLjcffCo7ekcHKsQ4hcV/eaK47EPEWh+ZN1jr h3rgtP1Xw7uuaiHIQfMgwPzlvP5M+sv+PwPxx1Mp8SwXITzcfLoe6U05Rl FB3z5gZHcNGTF44n/771B3SEx+de0+c9uogxuSdvIlnPolIewIlD0TxYut Bg5QWK5S2XRRQao9QgfIVda+Ci3nTI9l8Pqdq9et3Msd24YtFDq2fg== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 6E58AF8001B for ; Mon, 10 Jun 2019 18:26:13 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 10 Jun 2019 18:26:12 -0400 Message-ID: <22952181.EZtIpUVr24@l5580> In-Reply-To: <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net> References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580> <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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: Mon, 10 Jun 2019 22:26:17 -0000 On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote: > > On May 27, 2019, at 6:59 PM, Scott Kitterman wrote: > > > > On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org wrote: > >> 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-04.txt > >> Pages : 11 > >> Date : 2019-05-27 > > > > There isn't much to this update. It corrects one typo and reverts the RUF > > MUST NOT as discussed on the list. As far as I'm aware there are no other > > pending issues in the WG with the draft. > > Hi Scott, I've reviewed the doc and have made some comments. Feel free to > dispose of them as you will. > > I had a hard time with the introduction. "sets of domains within a single > organization" and "lower level policy" left me not knowing what I was > reading. I'm unhappy just complaining, so I took a stab at this admittedly > difficult section. The original: > > DMARC [RFC7489] provides a mechanism for publishing organizational > policy information to email receivers. DMARC [RFC7489] allows policy > to be specified for both individual domains and sets of domains > within a single organization. For domains above the organizational > level in the DNS tree, policy can only be published for the exact > domain. There is no method available to such domains to express > lower level policy or receive feedback reporting for sets of domains. > This prevents policy application to non-existent domains and > identification of domain abuse in email, which can be important for > brand and consumer protection. > > My stab: > > DMARC [RFC7489] provides a mechanism for publishing organizational > policy information to email receivers. DMARC [RFC7489] allows policy > to be specified for both individual domains and for organizational > domains and their sub-domains > within a single organization. For TLDs and domains that exist between > TLDs and organization level domains, policy can only be published for the > exact domain. No method is available for such domains to express > policy or receive feedback reporting for sub-domains. > This missing method allows for the abuse of non-existent > organizational-level domains and prevents identification of domain abuse in > email. > > > The example section doesn't read like the rest of the draft and was hard for > me to read through. Original: > > This would provide policy and feedback for mail sent from > @gov.example, but not @tax.gov.example and there is no way to publish > an organizational level policy that would do so. While, in theory, > receivers could reject mail from non-existent domains, not all > receivers do so. Non-existence of the sending domain can be a factor > in a mail delivery decision, but is not generally treated as > definitive on its own. > > Again my stab: > > This DMARC record provides policy and a reporting destination for mail > sent from @gov.example. However, due to DMARC's current method of > discovering and applying policy at the organizational domain level, the > non-existent organizational domain of @tax.gov.example does not and cannot > fall under a DMARC policy. > > > I don't have too much more, I just got just caught up in the initial read. > This paragraph contains a construct that was confusing to me: > > This memo provides a simple extension to DMARC [RFC7489] to allow > operators of Public Suffix Domains (PSDs) to express policy for > groups of subdomains, extends the DMARC [RFC7489] policy query > functionality to detect and process such a policy, describes receiver > feedback for such policies, and provides controls to mitigate > potential privacy considerations associated with this extension. > > ^^^ why "groups of subdomains" and not just "subdomains"? One step further, > why not "express policy at the level of the PSD that covers all > organizational domains that do not explicitly publish DMARC records"? > > > OK, two more things: > > 2.3. Longest PSD > > Organizational Domain (DMARC [RFC7489] Section 3.2) with one label > removed. > > ^^^ "one left-most label removed"? > > > Last thing: Security considerations might call out DNS cache poisoning as a > way to get reports for a PSD. Applies to vanilla DMARC too, but the scope > and potential breadth of information with PSD-DMARC is really interesting. > I imagine an attack that gets .COM listed into the PSD Registry for a > specific report generator.. combined with cache poisoning and the poor > report generator would probably explode at best. Thanks. I think those are all good comments. I can crank out an update or wait until after WGLC as the chairs prefer. Scott K From nobody Mon Jun 10 15:31:14 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0391200E5 for ; Mon, 10 Jun 2019 15:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=juyUmlnb; dkim=pass (2048-bit key) header.d=kitterman.com header.b=aUCLChf9 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 xnbcmLniu7Wo for ; Mon, 10 Jun 2019 15:31:10 -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 DF615120025 for ; Mon, 10 Jun 2019 15:31:09 -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 F2000F807AB for ; Mon, 10 Jun 2019 18:30:38 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1560205838; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ZFzWRGP+RX0JLe6g8eg71uDoaLJsDiH8SwB0sl6id4Y=; b=juyUmlnbzflUuK5u4ZbiNaeFqKYuj0NPFPAJy1TXnia3/Pizxp580BfF apa7bMNvEAt73M9htS5DBjkImYP7DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1560205838; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ZFzWRGP+RX0JLe6g8eg71uDoaLJsDiH8SwB0sl6id4Y=; b=aUCLChf9bj91L5Vlue9kPX6D81vJbxKapyfJOF4DnR0udhQFUx83cA63 mFHUFZJxgGYs+sGeYzoUxc3ryKsFkxNoXAekSIQzimLQvtOcA9/5OOU0HN 4VVYBGjkdbVm9gT6RSQwzAXZqA1jMml5NNmkYCLP1m18F+UW07FqYnXutQ MsSccBs2+U/KnL0auOGtlxjWo5s01qhGDObhwZLlIe6/wPlRmbM2frQtqj 5QocRsLVFXvKXD7HMRcsVlllXEp+WY/mNHlh/Sa56eH7uMug1njQN0FDA9 uKy2St45o0N9ZV02XEDQr38G5jcm8D21WtkHa2GDLM2oHwmoMAdFOg== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id B9FAEF8001B for ; Mon, 10 Jun 2019 18:30:38 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 10 Jun 2019 18:30:38 -0400 Message-ID: <2221039.c73XDibtHi@l5580> In-Reply-To: References: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 22:31:12 -0000 On Friday, June 7, 2019 7:02:59 AM EDT Hollenbeck, Scott wrote: > From: dmarc On Behalf Of Craig Schwartz > Sent: Thursday, June 6, 2019 2:52 PM > To: Hollenbeck, Scott > Cc: dmarc@ietf.org > Subject: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd > > > > > > > >On Thursday, June 6, 2019 at 1:12 PM EDT Scott Hollenbeck wrote: > > > > >I recently had a chance to read through draft-ietf-dmarc-psd. If I > >understand it correctly (and I'm not sure that I do), the document > >suggests that it's possible for a TLD like ".com" >to be a PSD and a TXT > >record like "_dmarc.com" can be published in the com > >zone. I found this part of the draft confusing because it's not possible > >to add TXT records like that >to the com zone. It might help to explicitly > >note somewhere (perhaps in Section 2.2) that there may be policy > >restrictions in place that disallow the publication of DMARC policy > >>records in some DNS zones, including some top-level domain zones. > > > > > The purpose of the document is to convey technically how PSD DMARC can be > accomplished rather than who can or cannot undertake this due to policy > considerations. As the operator of .BANK and .INSURANCE, fTLD initiated > this stream of work with the IEFT because of the explicit prohibition by > ICANN from inserting TXT records in the DNS. The goal is to get to an RFC > that specifies the technical aspect of PSD DMARC and ultimately seek > ICANN's approval to allow publication of such a record in the DNS. In > contrast, gTLDs not under contract with ICANN such as .MIL and .GOV, who > are both involved in this work, do not have a contractual relationship with > ICANN and thus are not prohibited from this activity, and the same goes for > ccTLDs. > > > It would be helpful to the reader if the draft were either clear about > potential limitations to deployment or more descriptive about the domains > for which the approach can work. Right now, PSD DMARC cannot be deployed > ubiquitously. That reality should not be overlooked. I see your point, but I think it's probably out of scope. This is an IETF document and such restrictions are outside the IETF's control. Also, keep in mind that once an RFC is published, it is immutable. If that guidance changes, then there would be no way to correct the document without spinning up a whole new RFC process. Is there a public, stable reference that describes the restrictions? If so, it might make sense to reference it. If we can, I think that would be much better than 'hard coding' the current external policy in an RFC. Scott K From nobody Mon Jun 10 15:41:21 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0026B12006E for ; Mon, 10 Jun 2019 15:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Aud+3mVP; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Qd+2gYT7 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 2mFDs5RW4qoW for ; Mon, 10 Jun 2019 15:41:18 -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 B889312004A for ; Mon, 10 Jun 2019 15:41:17 -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 C2AB4F807AB for ; Mon, 10 Jun 2019 18:41: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=1560206476; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ourohpPKSGVUgWt0McqAhKkEEZqWL/T2MnYy4ENk8dQ=; b=Aud+3mVPQXr+Bb6W3nh4FEZA3orcdBoc1uIJrUVBqawPb8jfSGDm/EGo Bq0BngosI9PFn9dqu0jdAu75E9H1Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1560206476; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ourohpPKSGVUgWt0McqAhKkEEZqWL/T2MnYy4ENk8dQ=; b=Qd+2gYT7bPblnMqPwzbz4b9W/ggli5EgoojaamAldSjXacRfMGahmvbk cY4IpmdoKaxqjxjdj3Z+PFHsIjnKTMQGqGkEDTJ5hO/D9NlsogtLEMRhs/ EfvaVNHNXF+nynRggFDOUaFWhOylCT5MB+LA5wNdMGq7spfQPxNpHEN1Ga ZwkeDDLP7XP2Gw7uEzCRRxvI68IVU+yVcGR7V0XKZ1GhGjh9+ongmtFHCU HOVhWWvnWeGTKLt7aAJjM2Slen1x+Xwm8CPxQbxnzOnCyMEVFDJZ+j2ig9 +Kxbzg+peIB1WVFD7AjT2kZUXu3CU9xkJZMiyUW+Sf39TWChTC+eaQ== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 90C01F8001B for ; Mon, 10 Jun 2019 18:41:16 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 10 Jun 2019 18:41:16 -0400 Message-ID: <5425365.YBKd1By0BY@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] DMARC PSD and non-existent subdomains 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, 10 Jun 2019 22:41:20 -0000 On Monday, June 10, 2019 8:07:25 AM EDT Richard C wrote: > Thanks for the question, Seth. > What would be the best way to incorporate this requirement? > The simplest possible way to address this use case is just to make sure > those existing but currently non-compliant domains just have a bare p=3Dn= one > record. Then they'll never fall back to the > gov.uk .uk&data=3D02%7C01%7CRichard.C%40ncsc.gov.uk%7C5e404b44633f4f62576c08d6e5= 58b35 > 3%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636948566460672014&sdata= =3Dihf4 > soMa8kR%2BcGFwjiIwgy9iHDnrnKLkawsj0Zm9Mi4%3D&reserved=3D0> record. There'= s no > risk to inadvertently breaking mail here. =20 > Is it remotely realistic for you to offer this guidance? If you're already > saying that p=3Dreject is required, how painful is it to advertise that a= ny > domain without a DMARC record will get p=3Dreject by default unless it > explicitly puts p=3Dnone in? =20 > I wish that publishing guidance resulted in swift adoption of it but > unfortunately it=E2=80=99s not so simple. We already have guidance publis= hed > requesting that organisations configure DMARC on their gov.uk domain > (starting at =E2=80=98none=E2=80=99 and progressing to =E2=80=98reject=E2= =80=99 as they gain confidence). > The problem is we have ~3500 domains in use, many by smaller organisations > with limited technical ability. Whilst we=E2=80=99ll continue to work tow= ards > helping them all deploy DMARC, realistically there will be a long tail to > adoption, hence our interest in support for different policies for the > existent and non-existent subdomains in DMARC PSD. =20 > Presumably other PSDs that aren=E2=80=99t brand new will have this proble= m too? I=E2=80=99m > interested to hear whether we=E2=80=99re on our own or not. As written, DMARC (RFC 7489) has the option to express different policy for= =20 subdomains (sp=3D tag). Perhaps we could address this case in PSD DMARC by= =20 leveraging that feature. PSD DMARC is the first time there is any DMARC related explicit guidance on= =20 non-existent sub-domains. If we made it a rule that non-existent sub-domai= ns=20 use the domain level (p=3D) policy and existent sub-domains use the sub-dom= ain=20 policy (sp=3D) then I believe the affect you are after is achievable. Assuming p=3Dreject and sp=3Dnone at the PSD level, the result would be: existing org domain (or sub) with DMARC record =3D use org policy existing org domain (or sub) with no DMARC record =3D None policy Non-existing org domain (or sub) with DMARC record =3D Reject policy PSD domain =3D Reject policy That would be a non-trivial increase in implementation complexity for=20 receivers, so I think we need some discussion about if there is consensus t= o=20 take this on. Scott K From nobody Mon Jun 10 18:08:16 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9B412008D for ; Mon, 10 Jun 2019 18:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2POJljVsedYv for ; Mon, 10 Jun 2019 18:08:13 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 D68E7120048 for ; Mon, 10 Jun 2019 18:08:12 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id x22so2156121itl.2 for ; Mon, 10 Jun 2019 18:08:12 -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=W51H/9j5Y6XNIc2dqE5DJyJuXOd893BdWwXJIFIUFDY=; b=U9NFrKuz2wrzhRW0HBgNj3UNmPGa2r8kDkHJwU51XohvhMWxonjgHArpsfMqgHwxZJ YkMzMTBACKAGYfiDY/pYEmuysiv3nbuzF75kunnGz0vUo7tjo7tSBXVE48phvqOky/84 IN7aonceBZQi5mZB0tBbeklOyuY9n4w0fuzeQ= 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=W51H/9j5Y6XNIc2dqE5DJyJuXOd893BdWwXJIFIUFDY=; b=pCbi99PVkQ+8YqpI8vUBjxqsUThHMhZEcylDHUptx9XKhJRQMYF/lP2uvUiOLgUTt8 wDWbsmvzHHAGIVnTNUSq4AfXI0huSCQ2iOF0oDJLARCR3jGBPoM9Zxsx86uBIzgi9f1w zKQAPwbK7mX4H+ltH55zlPBeZQk9BO3qm9lniYEQQg3wsrOMFmS12kBBk3tYMwTqOqKu pjBmTl62NDRGsmr0NdWQgG2s9WED2ZJMxw6cS8zzqTwbbF4g2qEbz2TqgYKR/TVcNHmn fXDaCwNPP4TTk1z/fGzrjMJpdgUfn8tnnftdFASDDSmEWtjXF0BlevUL7lIE9yVv51R2 ufcw== X-Gm-Message-State: APjAAAX17Ss9mB5kPfON476hmJl6e97PuGhqvFjwOB7K4dYP73xJR9gY +MLexQptr9psBy2y9efuitp4DKkLOgR2mhCTHGjMfQ== X-Google-Smtp-Source: APXvYqwKG2p5wdJco2mksay6wMfdaOiG153BqgKKMej1x2wAG1sNY5Vu8fRX5CjQVN33TYHujII/kEt1SPTDz6R+MSM= X-Received: by 2002:a02:1649:: with SMTP id a70mr49180495jaa.116.1560215291770; Mon, 10 Jun 2019 18:08:11 -0700 (PDT) MIME-Version: 1.0 References: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> <2221039.c73XDibtHi@l5580> In-Reply-To: <2221039.c73XDibtHi@l5580> From: "Kurt Andersen (b)" Date: Tue, 11 Jun 2019 09:07:59 +0800 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003d733e058b01eeb8" Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 11 Jun 2019 01:08:15 -0000 --0000000000003d733e058b01eeb8 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 11, 2019 at 6:31 AM Scott Kitterman wrote: > On Friday, June 7, 2019 7:02:59 AM EDT Hollenbeck, Scott wrote: > > > > It would be helpful to the reader if the draft were either clear about > > potential limitations to deployment or more descriptive about the domains > > for which the approach can work. Right now, PSD DMARC cannot be deployed > > ubiquitously. That reality should not be overlooked. > > I see your point, but I think it's probably out of scope. This is an IETF > document and such restrictions are outside the IETF's control. Also, keep > in > mind that once an RFC is published, it is immutable. If that guidance > changes, then there would be no way to correct the document without > spinning > up a whole new RFC process. > > Is there a public, stable reference that describes the restrictions? If > so, > it might make sense to reference it. If we can, I think that would be > much > better than 'hard coding' the current external policy in an RFC. > Including this information in the draft would be counter-productive. A large part of this effort is to document the desired handling so that the RFC can be used as documentation to support a change in ICANN policy. --Kurt --0000000000003d733e058b01eeb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 11, 2019 at 6:31 AM Scott Kit= terman <sklist@kitterman.com= > wrote:
On Friday, June 7, 2019 7:02:59 AM EDT Hollenbeck, S= cott wrote:
>
> It would be helpful to the reader if the draft were either clear about=
> potential limitations to deployment or more descriptive about the doma= ins
> for which the approach can work. Right now, PSD DMARC cannot be deploy= ed
> ubiquitously. That reality should not be overlooked.

I see your point, but I think it's probably out of scope.=C2=A0 This is= an IETF
document and such restrictions are outside the IETF's control.=C2=A0 Al= so, keep in
mind that once an RFC is published, it is immutable.=C2=A0 If that guidance=
changes, then there would be no way to correct the document without spinnin= g
up a whole new RFC process.

Is there a public, stable reference that describes the restrictions?=C2=A0 = If so,
it might make sense to reference it.=C2=A0 If we can, I think that would be= much
better than 'hard coding' the current external policy in an RFC.

Including this information in the draft w= ould be counter-productive. A large part of this effort is to document the = desired handling so that the RFC can be used as documentation to support a = change in ICANN policy.

--Kurt=C2=A0
--0000000000003d733e058b01eeb8-- From nobody Tue Jun 11 04:55:45 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B561200FD for ; Tue, 11 Jun 2019 04:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=verisign.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 yFotVPtuOW_Z for ; Tue, 11 Jun 2019 04:55:41 -0700 (PDT) Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 A3425120043 for ; Tue, 11 Jun 2019 04:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=11614; q=dns/txt; s=VRSN; t=1560254140; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=+mcODi84KX/rf3jyfyy1GRn3fzMgjEkMopynpCEWAoQ=; b=en+Az37cPeJpq1RCnX58ODM0NPbtB1v8b8gy7YRxCfz9u0gtAi0CzdiZ zbLXw/0nwLRcaOKWVKvBNZbIUhxz3tqfLXOlvQtyW90bIEjurcoLX/UtL MY7Er74q2YW/vxLJlzxjg5zk1woXaNI6MuvkDeLFiwsFqivtnCSTO6imB s3Xp1XGjQifgaGrsXrwFxbI/b1X3FsWxpZjHslb7nzs0cqnaUa7kvcC3N kBqrCPNRcZ9ErvDZLb7vaeondb1yGtlEKxP0C+ULFFqNdVJrtd2uOSKGz SJNf3MhV3pPdecXyNHmYnjAEk05ekGVOVsOc+o0LwGF+xMUenJ7/VKWhn g==; X-IronPort-AV: E=Sophos;i="5.63,579,1557201600"; d="scan'208,217";a="7828611" IronPort-PHdr: =?us-ascii?q?9a23=3AqZegWR3zII0NPR9wsmDT+DRfVm0co7zxezQtwd?= =?us-ascii?q?8ZsesWL/nxwZ3uMQTl6Ol3ixeRBMOHsqsC0reL+PqwEUU7or+5+EgYd5JNUx?= =?us-ascii?q?JXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQ?= =?us-ascii?q?viPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCegbb9oMRm7rQXcusYIjYZhN6081g?= =?us-ascii?q?bHrnxUdupM2GhmP0iTnxHy5sex+J5s7SFdsO8/+sBDTKv3Yb02QaRXAzo6PW?= =?us-ascii?q?814tbrtQTYQguU+nQcSGQWnQFWDAXD8Rr3Q43+sir+tup6xSmaIcj7Rq06VD?= =?us-ascii?q?i+86tmTgLjhSEaPDA77W7XkNR9gqJFrhy8uxxxzY3aYI+XO/p/YqzScsgXSn?= =?us-ascii?q?BdUsZTTSFNHp+wYokJAuEcPehYtY79p14WoBewBwesA+fvyjtWiX/wxqI1zf?= =?us-ascii?q?guEQLe0Ac9AtwBrHPUrMnpNKscTOu4y7LIzTXEb/NS3Tfy9o7IfQs/rv6QXr?= =?us-ascii?q?J9atTRxlc1FwPElVWQqIPlPzWP2usRtGib6vNtWOSygGAprAFxpyKgxsYqio?= =?us-ascii?q?TRiIMUxF7F+T92wIYyO920UlN7Yd2iHZBNtC+aL5N7Tt4+T21ypSo3yLMLtY?= =?us-ascii?q?SmcCUKxpkr3RHSZviff4SV/h7vTvudLDVkiH5/Zb6yiBW//VK9xuD/TsW03k?= =?us-ascii?q?hFoylZntTJs30A1QDc5tSdRfZ440uuxSqA2gXT5+5ZP080m6/WJpo8zbEtiJ?= =?us-ascii?q?Uet1nIEDXsl0XslqCWc10p+u2v6+v6fLrrvoScN4poigHmNaQuh9C/Dfw4Mg?= =?us-ascii?q?cQW2ib/vyx2aD/80PhXblFjuU4nKbYv5zGO8gXvLC5DBNS0oY58xazFS2p38?= =?us-ascii?q?kCkXkZNlJFYxSHg5L1NFHJJfD0Ffa/g1Kynzd33/3KI6HtDo/QInXBnrrtZ6?= =?us-ascii?q?tx5k5SxQYpwt1S44pYCrQbL/LyXk/xusbYDhg8MwGs2ObnCNJ91ocaWW2RBK?= =?us-ascii?q?+WK73dvkOL5u80PemDepUVuDfmK/gk6P7ui2U1lkMafamsxZcXcmy3Hux6I0?= =?us-ascii?q?WFZnrhmtQBHnwNvgoiTOznk0CNUSRQZ3avRaI8+is3B56hDYfGXoqtmqCO3D?= =?us-ascii?q?+nHp1KYWBLEkuMEXTsd4WFQPcMdDmfIsxgkjwYSbiuVZUh1RS0uw/80bZoMu?= =?us-ascii?q?3U+igAv5L5yNd1//HTlQ019TFsEsud1nuCT3tokW4TRj85wrx/oUJnxleEy6?= =?us-ascii?q?h4jK8QKdsGrfBDVRs6HZLGzPFgF5b5XQeLNoOKQlG6Qv2qGzIsVM53yNgLNQ?= =?us-ascii?q?I1Uc6hihHYwwKpAqMJmqaODZpy+aXZlTClPMV5ym3a/Kogk0UrWM5GMyutga?= =?us-ascii?q?sppCbJAIuc2WWek6Knc64R1y2JvFyIynaS9gkMSw53VaHIW3oSbUj+s9nj51?= =?us-ascii?q?jDQLnoArMiZFgSgfWeI7dHP4W6xW5NQ+3ubYzT?= X-IPAS-Result: =?us-ascii?q?A2EEAAD4lf9c/zGZrQpkGgEBAQEBAgEBAQEHAgEBAQGBU?= =?us-ascii?q?QUBAQEBCwGBDoFsgSwKhAuDSoRSiimCO5hhgXsJAQEBAQEBAQEBBwElCgEBA?= =?us-ascii?q?oN4RgIXgws0CQ4BAwEBAQQBAQEBAwEBAQKBBQyCOiIcTWoBAQEBAQEBIwIfU?= =?us-ascii?q?QEBAQEDIwpMEAIBCBEEAQEBJwMCAgIwFAkIAgQBDQUIgxuBHXyoZ4Exg3WBU?= =?us-ascii?q?oRzgTQBi3OBQT6EIz6CYQSBdh8IgkyCWASOJoRwlhoDBgKCEIZFjHgjlyCNF?= =?us-ascii?q?pY+AgQCBAUCFYFPgX0MCHCDPAmNcIJZco5vgSEBAQ?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 11 Jun 2019 07:55:37 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Tue, 11 Jun 2019 07:55:37 -0400 From: "Hollenbeck, Scott" To: "kboth@drkurt.com" , "sklist@kitterman.com" CC: "dmarc@ietf.org" Thread-Topic: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd Thread-Index: AQHVH9w8J4x0Q67D40m0K6H+JWCbDKaV542AgABqVHA= Date: Tue, 11 Jun 2019 11:55:37 +0000 Message-ID: References: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> <2221039.c73XDibtHi@l5580> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: multipart/alternative; boundary="_000_f0c4a032899a47f1991f5174ca43662cverisigncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 11 Jun 2019 11:55:43 -0000 --_000_f0c4a032899a47f1991f5174ca43662cverisigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KDQpGcm9tOiBkbWFyYyA8ZG1hcmMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IEt1cnQgQW5kZXJzZW4gKGIpDQpTZW50OiBNb25kYXksIEp1bmUgMTAsIDIwMTkgOTowOCBQTQ0K VG86IFNjb3R0IEtpdHRlcm1hbiA8c2tsaXN0QGtpdHRlcm1hbi5jb20+DQpDYzogZG1hcmNAaWV0 Zi5vcmcNClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtkbWFyYy1pZXRmXSBQU0RzIGluIGRyYWZ0 LWlldGYtZG1hcmMtcHNkDQoNCg0KDQpPbiBUdWUsIEp1biAxMSwgMjAxOSBhdCA2OjMxIEFNIFNj b3R0IEtpdHRlcm1hbiA8c2tsaXN0QGtpdHRlcm1hbi5jb208bWFpbHRvOnNrbGlzdEBraXR0ZXJt YW4uY29tPj4gd3JvdGU6DQoNCiAgIE9uIEZyaWRheSwgSnVuZSA3LCAyMDE5IDc6MDI6NTkgQU0g RURUIEhvbGxlbmJlY2ssIFNjb3R0IHdyb3RlOg0KICAgPg0KICAgPiBJdCB3b3VsZCBiZSBoZWxw ZnVsIHRvIHRoZSByZWFkZXIgaWYgdGhlIGRyYWZ0IHdlcmUgZWl0aGVyIGNsZWFyIGFib3V0DQog ICA+IHBvdGVudGlhbCBsaW1pdGF0aW9ucyB0byBkZXBsb3ltZW50IG9yIG1vcmUgZGVzY3JpcHRp dmUgYWJvdXQgdGhlIGRvbWFpbnMNCiAgID4gZm9yIHdoaWNoIHRoZSBhcHByb2FjaCBjYW4gd29y ay4gUmlnaHQgbm93LCBQU0QgRE1BUkMgY2Fubm90IGJlIGRlcGxveWVkDQogICA+IHViaXF1aXRv dXNseS4gVGhhdCByZWFsaXR5IHNob3VsZCBub3QgYmUgb3Zlcmxvb2tlZC4NCg0KICAgSSBzZWUg eW91ciBwb2ludCwgYnV0IEkgdGhpbmsgaXQncyBwcm9iYWJseSBvdXQgb2Ygc2NvcGUuICBUaGlz IGlzIGFuIElFVEYNCiAgIGRvY3VtZW50IGFuZCBzdWNoIHJlc3RyaWN0aW9ucyBhcmUgb3V0c2lk ZSB0aGUgSUVURidzIGNvbnRyb2wuICBBbHNvLCBrZWVwIGluDQogICBtaW5kIHRoYXQgb25jZSBh biBSRkMgaXMgcHVibGlzaGVkLCBpdCBpcyBpbW11dGFibGUuICBJZiB0aGF0IGd1aWRhbmNlDQog ICBjaGFuZ2VzLCB0aGVuIHRoZXJlIHdvdWxkIGJlIG5vIHdheSB0byBjb3JyZWN0IHRoZSBkb2N1 bWVudCB3aXRob3V0IHNwaW5uaW5nDQogICB1cCBhIHdob2xlIG5ldyBSRkMgcHJvY2Vzcy4NCg0K ICAgSXMgdGhlcmUgYSBwdWJsaWMsIHN0YWJsZSByZWZlcmVuY2UgdGhhdCBkZXNjcmliZXMgdGhl IHJlc3RyaWN0aW9ucz8gIElmIHNvLA0KICAgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byByZWZlcmVu Y2UgaXQuICBJZiB3ZSBjYW4sIEkgdGhpbmsgdGhhdCB3b3VsZCBiZSBtdWNoDQogICBiZXR0ZXIg dGhhbiAnaGFyZCBjb2RpbmcnIHRoZSBjdXJyZW50IGV4dGVybmFsIHBvbGljeSBpbiBhbiBSRkMu DQoNCg0KDQogICBJbmNsdWRpbmcgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgZHJhZnQgd291bGQg YmUgY291bnRlci1wcm9kdWN0aXZlLiBBIGxhcmdlIHBhcnQgb2YgdGhpcyBlZmZvcnQgaXMgdG8g ZG9jdW1lbnQgdGhlIGRlc2lyZWQgaGFuZGxpbmcgc28gdGhhdCB0aGUgUkZDIGNhbiBiZSB1c2Vk IGFzIGRvY3VtZW50YXRpb24gdG8gc3VwcG9ydCBhIGNoYW5nZSBpbiBJQ0FOTiBwb2xpY3kuDQoN Cg0KDQogICBbU0FIXTogVGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBFeHBlcmltZW50YWwgc3Rh dHVzLiBJdCB3b3VsZCBiZSBpcnJlc3BvbnNpYmxlIHRvIG5vdCBkb2N1bWVudCBjb25kaXRpb25z IHVuZGVyIHdoaWNoIHRoZSBleHBlcmltZW50IGNhbiBvciBjYW5ub3QgYmUgY29uZHVjdGVkLiBT ZWN0aW9uIDMuMiBvZiBSRkMgNzQ4OSBkb2VzIGEgZ29vZCBqb2Igb2YgZGVzY3JpYmluZyBvcmdh bml6YXRpb25hbCBkb21haW4gdmFyaWFiaWxpdHk7IG1pZ2h0IHRoZXJlIGJlIHNvbWUgd2F5IG9m IGRlZmluaW5nIGEgUFNEIHRoYXTigJlzIGJhc2VkIG9uIHRoZSBkZWZpbml0aW9uIG9mIGFuIFJG QyA3NDg5IG9yZ2FuaXphdGlvbmFsIGRvbWFpbj8gVGhhdCB3b3VsZCBhZGRyZXNzIG15IGNvbmNl cm4sIGFuZCBpdCBzZWVtcyBsaWtlIGl0IHNob3VsZCBiZSBwb3NzaWJsZSBnaXZlbiB0aGF0IHRo ZSBkZWZpbml0aW9uIG9mIGEg4oCcTG9uZ2VzdCBQU0TigJ0gaW4gU2VjdGlvbiAyLjMgaXMgYmFz ZWQgb24gdGhlIG9yZ2FuaXphdGlvbmFsIGRvbWFpbiBkZXNjcmlwdGlvbiBmcm9tIFJGQyA3NDg5 Lg0KDQoNCg0KICAgT24gYSBzbGlnaHRseSBkaWZmZXJlbnQgbm90ZSwgU2VjdGlvbiAyLjIgYWxz byBzYXlzIHRoaXM6DQoNCg0KDQogICDigJxQU0QgRE1BUkMgaW5jbHVkZXMgYWxsIHB1YmxpYyBk b21haW5zIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbCBsZXZlbCBpbiB0aGUgdHJlZSwgZS5nLiwg Ii5nb3YudWsiLuKAnQ0KDQoNCg0KICAgUmVnaXN0cmF0aW9uIGluIC5nb3YudWsgaXMgcmVzdHJp Y3RlZCAoaHR0cHM6Ly93d3cuZ292LnVrL2dvdmVybm1lbnQvcHVibGljYXRpb25zL25hbWluZy1h bmQtcmVnaXN0ZXJpbmctZ292ZXJubWVudC13ZWJzaXRlcykuIFdoYXQgZXhhY3RseSBpcyBtZWFu dCBieSDigJxwdWJsaWMgZG9tYWluc+KAnT8NCg0KDQoNCiAgIFNjb3R0DQoNCg0KDQo= --_000_f0c4a032899a47f1991f5174ca43662cverisigncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZG1hcmMgJmx0O2Rt YXJjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpLdXJ0IEFuZGVy c2VuIChiKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTAsIDIwMTkgOTowOCBQTTxi cj4NCjxiPlRvOjwvYj4gU2NvdHQgS2l0dGVybWFuICZsdDtza2xpc3RAa2l0dGVybWFuLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IGRtYXJjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtF WFRFUk5BTF0gUmU6IFtkbWFyYy1pZXRmXSBQU0RzIGluIGRyYWZ0LWlldGYtZG1hcmMtcHNkPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1 ZSwgSnVuIDExLCAyMDE5IGF0IDY6MzEgQU0gU2NvdHQgS2l0dGVybWFuICZsdDs8YSBocmVmPSJt YWlsdG86c2tsaXN0QGtpdHRlcm1hbi5jb20iPnNrbGlzdEBraXR0ZXJtYW4uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gRnJpZGF5LCBKdW5lIDcsIDIwMTkgNzowMjo1OSBBTSBFRFQgSG9s bGVuYmVjaywgU2NvdHQgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0IHdvdWxkIGJlIGhl bHBmdWwgdG8gdGhlIHJlYWRlciBpZiB0aGUgZHJhZnQgd2VyZSBlaXRoZXIgY2xlYXIgYWJvdXQ8 YnI+DQomZ3Q7IHBvdGVudGlhbCBsaW1pdGF0aW9ucyB0byBkZXBsb3ltZW50IG9yIG1vcmUgZGVz Y3JpcHRpdmUgYWJvdXQgdGhlIGRvbWFpbnM8YnI+DQomZ3Q7IGZvciB3aGljaCB0aGUgYXBwcm9h Y2ggY2FuIHdvcmsuIFJpZ2h0IG5vdywgUFNEIERNQVJDIGNhbm5vdCBiZSBkZXBsb3llZDxicj4N CiZndDsgdWJpcXVpdG91c2x5LiBUaGF0IHJlYWxpdHkgc2hvdWxkIG5vdCBiZSBvdmVybG9va2Vk Ljxicj4NCjxicj4NCkkgc2VlIHlvdXIgcG9pbnQsIGJ1dCBJIHRoaW5rIGl0J3MgcHJvYmFibHkg b3V0IG9mIHNjb3BlLiZuYnNwOyBUaGlzIGlzIGFuIElFVEYgPGJyPg0KZG9jdW1lbnQgYW5kIHN1 Y2ggcmVzdHJpY3Rpb25zIGFyZSBvdXRzaWRlIHRoZSBJRVRGJ3MgY29udHJvbC4mbmJzcDsgQWxz bywga2VlcCBpbiA8YnI+DQptaW5kIHRoYXQgb25jZSBhbiBSRkMgaXMgcHVibGlzaGVkLCBpdCBp cyBpbW11dGFibGUuJm5ic3A7IElmIHRoYXQgZ3VpZGFuY2UgPGJyPg0KY2hhbmdlcywgdGhlbiB0 aGVyZSB3b3VsZCBiZSBubyB3YXkgdG8gY29ycmVjdCB0aGUgZG9jdW1lbnQgd2l0aG91dCBzcGlu bmluZyA8YnI+DQp1cCBhIHdob2xlIG5ldyBSRkMgcHJvY2Vzcy48YnI+DQo8YnI+DQpJcyB0aGVy ZSBhIHB1YmxpYywgc3RhYmxlIHJlZmVyZW5jZSB0aGF0IGRlc2NyaWJlcyB0aGUgcmVzdHJpY3Rp b25zPyZuYnNwOyBJZiBzbywgPGJyPg0KaXQgbWlnaHQgbWFrZSBzZW5zZSB0byByZWZlcmVuY2Ug aXQuJm5ic3A7IElmIHdlIGNhbiwgSSB0aGluayB0aGF0IHdvdWxkIGJlIG11Y2ggPGJyPg0KYmV0 dGVyIHRoYW4gJ2hhcmQgY29kaW5nJyB0aGUgY3VycmVudCBleHRlcm5hbCBwb2xpY3kgaW4gYW4g UkZDLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW5jbHVkaW5nIHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIGRyYWZ0IHdvdWxkIGJl IGNvdW50ZXItcHJvZHVjdGl2ZS4gQSBsYXJnZSBwYXJ0IG9mIHRoaXMgZWZmb3J0IGlzIHRvIGRv Y3VtZW50IHRoZSBkZXNpcmVkIGhhbmRsaW5nIHNvIHRoYXQgdGhlIFJGQyBjYW4gYmUgdXNlZCBh cyBkb2N1bWVudGF0aW9uIHRvIHN1cHBvcnQgYSBjaGFuZ2UgaW4gSUNBTk4gcG9saWN5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bU0FIXTog VGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBFeHBlcmltZW50YWwgc3RhdHVzLiBJdCB3b3VsZCBi ZSBpcnJlc3BvbnNpYmxlIHRvIG5vdCBkb2N1bWVudCBjb25kaXRpb25zIHVuZGVyIHdoaWNoIHRo ZSBleHBlcmltZW50IGNhbiBvciBjYW5ub3QgYmUgY29uZHVjdGVkLiBTZWN0aW9uIDMuMiBvZiBS RkMgNzQ4OSBkb2VzIGEgZ29vZCBqb2Igb2YgZGVzY3JpYmluZyBvcmdhbml6YXRpb25hbCBkb21h aW4NCiB2YXJpYWJpbGl0eTsgbWlnaHQgdGhlcmUgYmUgc29tZSB3YXkgb2YgZGVmaW5pbmcgYSBQ U0QgdGhhdOKAmXMgYmFzZWQgb24gdGhlIGRlZmluaXRpb24gb2YgYW4gUkZDIDc0ODkgb3JnYW5p emF0aW9uYWwgZG9tYWluPyBUaGF0IHdvdWxkIGFkZHJlc3MgbXkgY29uY2VybiwgYW5kIGl0IHNl ZW1zIGxpa2UgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIGdpdmVuIHRoYXQgdGhlIGRlZmluaXRpb24g b2YgYSDigJxMb25nZXN0IFBTROKAnSBpbiBTZWN0aW9uIDIuMyBpcw0KIGJhc2VkIG9uIHRoZSBv cmdhbml6YXRpb25hbCBkb21haW4gZGVzY3JpcHRpb24gZnJvbSBSRkMgNzQ4OS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gYSBzbGlnaHRseSBkaWZmZXJlbnQgbm90ZSwgU2VjdGlvbiAyLjIg YWxzbyBzYXlzIHRoaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFBTRCBETUFSQyBpbmNs dWRlcyBhbGwgcHVibGljIGRvbWFpbnMgYWJvdmUgdGhlIG9yZ2FuaXphdGlvbmFsIGxldmVsIGlu IHRoZSB0cmVlLCBlLmcuLCAmcXVvdDsuZ292LnVrJnF1b3Q7LuKAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZWdpc3RyYXRpb24gaW4gLmdvdi51ayBpcyByZXN0cmljdGVkICg8YSBocmVmPSJo dHRwczovL3d3dy5nb3YudWsvZ292ZXJubWVudC9wdWJsaWNhdGlvbnMvbmFtaW5nLWFuZC1yZWdp c3RlcmluZy1nb3Zlcm5tZW50LXdlYnNpdGVzIj5odHRwczovL3d3dy5nb3YudWsvZ292ZXJubWVu dC9wdWJsaWNhdGlvbnMvbmFtaW5nLWFuZC1yZWdpc3RlcmluZy1nb3Zlcm5tZW50LXdlYnNpdGVz PC9hPikuIFdoYXQgZXhhY3RseQ0KIGlzIG1lYW50IGJ5IOKAnHB1YmxpYyBkb21haW5z4oCdPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TY290dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9iPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f0c4a032899a47f1991f5174ca43662cverisigncom_-- From nobody Tue Jun 11 08:12:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E27120181 for ; Tue, 11 Jun 2019 08:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKgauW8RdHgR for ; Tue, 11 Jun 2019 08:12:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94041200E5 for ; Tue, 11 Jun 2019 08:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560265965; bh=bijkzUcB5Hz1nDjyvz9Tst9uFRLudjg9AQyuTEAihtU=; l=2703; h=To:References:From:Date:In-Reply-To; b=ASONCcQoTH8DrxIaDzWmsU3si5Md/tKLOyMi/TuqZb9+eMB6hTYeMvs2HaFYoUGlj JfKi6hU+4naE+Ppwpj973pnKNKDVHCvAyfNZ28FtkT9PQTKRy3tnhNuR5bHuoelkAD O0iO9RYKG70fyszYDHUos3UsnloM9bTI1iZOJ1FffoXZKmfuV9hEzs0HAi1bG Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 11 Jun 2019 17:12:45 +0200 id 00000000005DC077.000000005CFFC4ED.00003196 To: dcrocker@bbiw.net, dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> Date: Tue, 11 Jun 2019 17:12:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 11 Jun 2019 15:12:50 -0000 On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote: > On 6/10/2019 1:17 AM, Alessandro Vesely wrote: >> On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: >> >>> Except that most users don't actually see that address because these days most >>> MUAs only display the display address. >> >> >> We often came across this realization.  Since DMARC hinges on that field, I >> think the spec should include some advice to MUA implementation. > > Unfortunately there is no 'advice' to give that has any utility. > > If you feel otherwise, please try to formulate it, including the basis for > believing it useful, and then try to get community support for it. I'd propose bullets like the following for Section 12.4: o In the MUA, it is safe to only show the display name if its correspondence to the email address can be verified by looking it up in the address book or similar storage. In case a display name compares equal to one that corresponds to a different email address, such discrepancy should be enhanced unless the two email addresses are established to be equivalent to each other. Email addresses are equivalent when they correspond to the same person, or to the same role within a given organization, or, in practice, when the user says that they are. o The authentication status of the message should be visible. >> A trust on first use (TOFU) approach would seem to be possible. > > In practical terms, what does that mean?  Who does what, exactly? A discrepancy can be enhanced by bold characters, by a pop-up, or by a beep and an alert message. Anything but silently displaying a familiar name which actually stands for something else. A user can then arrange her address book so as to make it clear to the MUA that a class of email addresses are equivalent to one another, in order to avoid meaningless alerts. >> Does this subject deserve a ticket? > > Since it has nothing to do with errors or problems with the current spec, I > don't see how to justify a ticket. Section 12.4 seems to have some problems. The first bullet should be reworked, because it can be understood as suggesting that in cases like, for example: From: "user@example.org via Bug Tracker" a _MUA_ should "execute the DMARC mechanism on the domain name found there rather than the domain name discovered originally." That sounds nonsense, first, because MUAs should rather base on A-R records added by the MX. Second, because checking example.org rather than example.com, in the example, would defeat the only workaround for indirect mail flows which seems to be working thus far. Best Ale -- From nobody Tue Jun 11 08:24:49 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA35D1202AE for ; Tue, 11 Jun 2019 08:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRaqO10y791b for ; Tue, 11 Jun 2019 08:24:40 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27B21202B0 for ; Tue, 11 Jun 2019 08:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560266677; bh=O6CeOdv9VBLmDinRiuZ7T5r3cpOZdH4tM96pN1Uzt7Q=; l=2188; h=To:References:From:Date:In-Reply-To; b=AUVgI7L1VU9BuM5N64jKur03gP8C/xaiNnYuFKYJWbjF6GeYYE/HUaSaI8MMQB1cF jomI9fjbrR007IMuqErXKHkSEjhrZNyTHGAuRbJeLAgpeg3VtHBmLUO7yjnjQRpx/V uDjY3XA5+YpErUfWGF+K2dDlGb8ZEfZxir+qltHH1aLfykKsR6+fFbn1Ro0ZC Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 11 Jun 2019 17:24:37 +0200 id 00000000005DC077.000000005CFFC7B5.000032AA To: dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <5CFEAE2E.90308@isdg.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <2c79eeb7-e829-928a-3d8e-d38d743414d4@tana.it> Date: Tue, 11 Jun 2019 17:24:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5CFEAE2E.90308@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 11 Jun 2019 15:24:43 -0000 On Mon 10/Jun/2019 21:23:26 +0200 Hector Santos wrote: > On 6/10/2019 4:17 AM, Alessandro Vesely wrote: >> On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: >> >>> Except that most users don't actually see that address because these days most >>> MUAs only display the display address. >> >> >> We often came across this realization.  Since DMARC hinges on that field, I >> think the spec should include some advice to MUA implementation. >> >> A trust on first use (TOFU) approach would seem to be possible.  On getting the >> same display name linked to a different domain part, a user would be required >> to configure the MUA's behavior for this particular name / domain. >> >> Does this subject deserve a ticket? >> > > Don't you think we might repeat and come to the same conclusions regarding MUA > considerations in this regard? > > The primary concern would be 5322.From "Display" spoofing with the theoretical > Multiple 5322.From headers potential exploit.  A 2010 proof of concept list > message example was showed it was possible to contain a valid DKIM signature > and with a spoofed From display from "President Obama:" > > http://mipassoc.org/pipermail/ietf-dkim/2010q4/014680.html > > This created a long threaded discussion, and if I recall, the topic was > repeated a few years later where I believe we had a consensus this was a > "RFC5322 Boundary Layer" issue where the MSA/MDA or the backend would be better > at handling the RFC5322 "validity" of an inbound message.  It would be a good > idea for receivers to do RFC5322 checking anyway instead of "passing the buck" > to the many different MUA vendors including the many legacy MUAs people still > enjoy today. > > If any protocol guidance is necessary here, IMO, it would be to repeat the > suggestion for RFC5322 validity/security checks SHOULD be done at the backend > to better protect the MUA end users using different Offline, Online and Hybrids > models of MUAs.  An inbound message with multiple 5322.From headers SHOULD be > invalided, rejected or discarded. +1, waiting until everybody signs From:From: is a bit... long-winded. Best Ale -- From nobody Tue Jun 11 08:38:17 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E57120278 for ; Tue, 11 Jun 2019 08:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ0b60P3SEEF for ; Tue, 11 Jun 2019 08:38:15 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D42712027A for ; Tue, 11 Jun 2019 08:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560267483; bh=e7D44+7hcxfBRu+FQB0P3y8Mo2sl04M/ZfZhpRggtAY=; l=1054; h=To:References:From:Date:In-Reply-To; b=C9fOoRHSegAvH5cxBoSNxj0Ii6TARizwLeHMxayVVCuSdNcTC3vLQ6jwouHXM/sNw bki3nRj3oH0HGM9uIS204HPacgnuQg/vDCOuyOTIgS1lrsRYjsLBLhtl6e1+ukCPcC RyV1xZnn7pYnbNXlqtdt4m89KYcyabBVPpGG4bHn2n31HAujbPHJ3VfPtTVYX Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 11 Jun 2019 17:38:03 +0200 id 00000000005DC02F.000000005CFFCADB.00003440 To: dmarc@ietf.org References: <5425365.YBKd1By0BY@l5580> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <4ba6fbe5-80f1-1b68-c61e-57cd1ad312e2@tana.it> Date: Tue, 11 Jun 2019 17:38:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5425365.YBKd1By0BY@l5580> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC PSD and non-existent subdomains 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, 11 Jun 2019 15:38:16 -0000 On Tue 11/Jun/2019 00:41:16 +0200 Scott Kitterman wrote: > On Monday, June 10, 2019 8:07:25 AM EDT Richard C wrote: > >> Presumably other PSDs that aren’t brand new will have this problem too? I’m >> interested to hear whether we’re on our own or not. > > As written, DMARC (RFC 7489) has the option to express different policy for > subdomains (sp= tag). Perhaps we could address this case in PSD DMARC by > leveraging that feature. > > PSD DMARC is the first time there is any DMARC related explicit guidance on > non-existent sub-domains. If we made it a rule that non-existent sub-domains > use the domain level (p=) policy and existent sub-domains use the sub-domain > policy (sp=) then I believe the affect you are after is achievable. Rather than altering p= and sp=, I'd add an np=, say, for non-existing domains: * It certainly would gather more attention by implementers, * Domain owners could monitor to check it. * It allows the main domain to have a non-reject policy. Best Ale -- From nobody Tue Jun 11 09:39:23 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592131203D3 for ; Tue, 11 Jun 2019 09:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=K04uzQHm; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=lMnht6/l 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 6Op10S8HD1Ra for ; Tue, 11 Jun 2019 09:38:48 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 606D2120386 for ; Tue, 11 Jun 2019 09:38:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6849; t=1560271099; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=5Zg9xYF5Q5Ay/Pux/jTa1F3vRNk=; b=K04uzQHmGJiklZQoGPQXryOKHjzc3Ga/hOe1V7+e+gKGNLtbgQ1mgE0myOqAYF 5SOFOOQ8Y/z68jrnNSBJ9OG9q2wrCA7ZDrGo9wGbgvX4xBRvfxbnZm5PrztJjPO6 9MulGOyq8+PiLh0f2ZBJK2kBtbCAy/4qS4P5wWZ5afmnU= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Tue, 11 Jun 2019 12:38:19 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1063538845.1.5672; Tue, 11 Jun 2019 12:38:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6849; t=1560270899; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4HDlfcY 2OP5gTocPD8LF2IrOBDkVMmYTugFwGIvp0RE=; b=lMnht6/lmL+ez9j+VT5vvGu /aT/malSf6Ll2RFnmi5DG/xlGEc6rdCbEmhTOvI1KRx0Q4OaBq4crN2WJ2OYo3ta U4S4yEHvLqtdbz2RKn86up73mgwu02LF2iGQy3D9ymHiV7Tva5rPYk/SVUPIjx23 qa4aw+/QJOebZELaXFak= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Tue, 11 Jun 2019 12:34:59 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2635754504.9.245780; Tue, 11 Jun 2019 12:34:58 -0400 Message-ID: <5CFFD8F7.9030109@isdg.net> Date: Tue, 11 Jun 2019 12:38:15 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> In-Reply-To: <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 11 Jun 2019 16:39:22 -0000 On 6/11/2019 11:12 AM, Alessandro Vesely wrote: > On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote: >> On 6/10/2019 1:17 AM, Alessandro Vesely wrote: >>> On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: >>> >>>> Except that most users don't actually see that address because these days most >>>> MUAs only display the display address. >>> >>> >>> We often came across this realization. Since DMARC hinges on that field, I >>> think the spec should include some advice to MUA implementation. >> >> Unfortunately there is no 'advice' to give that has any utility. >> >> If you feel otherwise, please try to formulate it, including the basis for >> believing it useful, and then try to get community support for it. > > > I'd propose bullets like the following for Section 12.4: > > o In the MUA, it is safe to only show the display name if its > correspondence to the email address can be verified by looking it up in > the address book or similar storage. In case a display name compares > equal to one that corresponds to a different email address, such > discrepancy should be enhanced unless the two email addresses are > established to be equivalent to each other. Email addresses are > equivalent when they correspond to the same person, or to the same role > within a given organization, or, in practice, when the user says that > they are. > > o The authentication status of the message should be visible. These are good for a online MUA system where the backend has both verification and display controls. With an offline MUA, where we have store and forward, there is the "who was the verifying domain" trust issue. If the backend is not going to clean it up, make it safe for the user's MUA to pick the mail, then it has wider chance of user security concerns and issues due to lack of persistency and consistency in offline MUA behavior. With a hybrid, the MUA is more in sync with the backend operations, so rather than the MUA doing the calculations based on the data it has, the backend supplies the indicators, public or proprietary, for the compliant hybrid MUA to display. As a developer of MUAs, offline, online and a hybrid, with Native Gui, Text-based (ANSI/VT100) and HTML-based Messaging UIs, there has been many single sourcing and integration considerations. Overall, we only have open standard RFC5322 protocol to communicate between the MSA/MTA/MDA and MUA. I think the "battle" or "dilemma" has been the trust of the A-R header verifying.domain" header created by the MDA mail receiving/inbound components performing the DKIM verification. Can the MUA trust the verifying.domain? A possible MUA design tip could be to add something equal to: [_] Trust the Authentication-Result Verifying Domain IFF it matches the the Authentication Login (Mail Pickup) Domain Server. or something along those lines. With the MUA I used personally (TBIRD), I created a rule to highlight, color tag the Pass (Green) Fail (Red) DKIM results read from my backend verifying domain A-R header. Others A-R beader are ignored. Each MUA can implement this idea their own way. But it is important to consider the different MUA designs. With Online, like a Web-Mail interface, this offers 100% backend UI design controls, single sourced and safer for the end-user. It is easier to explore the integration requirements. With offline/hybrid MUA system needs are more complex and the ideas will need to be translated into a RFC5322 meta-headers. Of course, the offline MUA can do the DKIM verification itself. It has always been in interesting idea to see what comes about. While I recall some earlyr 3rd party Add-on attempts, I personally have not see too much in this area with MUA vendors themselves. We won't see persistency and consistency here. Hybrids is what I expect more to happen where the backend can add more "meta-data" designed for the proprietary hybrid MUA to understand, and its not just for DKIM security but a broad range of MUA A/A concepts. >>> A trust on first use (TOFU) approach would seem to be possible. >> >> In practical terms, what does that mean? Who does what, exactly? > > A discrepancy can be enhanced by bold characters, by a pop-up, or by a beep and > an alert message. Anything but silently displaying a familiar name which > actually stands for something else. > > A user can then arrange her address book so as to make it clear to the MUA that > a class of email addresses are equivalent to one another, in order to avoid > meaningless alerts. Good ideas for MUA implementations, not sure how we can standardize this though. Lots of psychology involved. In fact, with the Red/Blue color tagging I've have in Tbird, I haven't been paying too much attention to the RED tags I see due to DKIM verification failures. If I see both a red and blue, that tells me most likely an original DKIM signature was broken (RED) but it was resigned with 2nd list server signature (GREEN). For Private 1 to 1 communications, I would not expect to see RED here because there should be no middle ware interference, but there are non-list related indirect scenarios that can cause this. I wouldn't expect it though. > > >>> Does this subject deserve a ticket? >> >> Since it has nothing to do with errors or problems with the current spec, I >> don't see how to justify a ticket. > > > Section 12.4 seems to have some problems. The first bullet should be reworked, > because it can be understood as suggesting that in cases like, for example: > > From: "user@example.org via Bug Tracker" > > a _MUA_ should "execute the DMARC mechanism on the domain name found there > rather than the domain name discovered originally." That sounds nonsense, > first, because MUAs should rather base on A-R records added by the MX. This is what I meant above. You are proposing a trust concept for the MUA on which A-R record to "believe." The MUA needs trust on the meta-data headers it sees. In theory, it could trust (with higher confidence) the headers added by the user's mail hosting provider or the server the user logged into, or basically the last processing machine at the hosting provider. Maybe Murray can comment on this, I don't recall seeing a discussion where the A-R verifying.domain was tied to some trusted hosted domain we have confidence in. Can the MX or MDA domains be associated with the A-R verifying the domain? Right now, the only A-R header that can be trusted is the last one created by the receiving domain for in-house use, or a Web-mail interface or for a hybrid. For a offline reader, the user will need to make that the RFC5322 scripting designs or the advanced MUA can offer an option to make that trust association. -- HLS From nobody Tue Jun 11 09:54:40 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD8012022E for ; Tue, 11 Jun 2019 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Bu1Nge96; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=TBi7DVKu 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 8NQI1LUXaAeb for ; Tue, 11 Jun 2019 09:54:37 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED4E120145 for ; Tue, 11 Jun 2019 09:54:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2053; t=1560272069; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=U0PcbPR42n2Zq4HbWziGW5/p8n4=; b=Bu1Nge96PmbPI6JBwIWjspBVPUABbSrn5S2ZFquV7tzk37RfMGJgf5tlGWyLRE jyrj/ZAmW1U8jLSkEq7iWCbGbeLXkmC2Zdg8up/UmHQ7BBNOoCrv3U349Ah8YVcU ijFMpksU/kRf24l9Itqnn1cmvZ+xyIc0GDwywu8NZON/A= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Tue, 11 Jun 2019 12:54:29 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1064508906.1.3608; Tue, 11 Jun 2019 12:54:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2053; t=1560271869; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Da/ZCoF /tjuqZGwC+abJgnV92ICTABXsCcJ+Fwdn2wE=; b=TBi7DVKuVBrFTq7YUSFcJK2 GVRJMXOBthCGcfXVLWzrC9PR3FhXOz3dVeDJexNLHeue2ql1w+1SGrqT5UjpmgNZ EOGSXOKOIObbqzYfRpcfOs0FkAm9f8LWhK+Ff6uOh/PnpyiJlz9Tvc8awR7tdcGH iEZTIhnd0XFO9jL5PB1c= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Tue, 11 Jun 2019 12:51:09 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2636724270.9.303252; Tue, 11 Jun 2019 12:51:08 -0400 Message-ID: <5CFFDCC1.5080502@isdg.net> Date: Tue, 11 Jun 2019 12:54:25 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5425365.YBKd1By0BY@l5580> <4ba6fbe5-80f1-1b68-c61e-57cd1ad312e2@tana.it> In-Reply-To: <4ba6fbe5-80f1-1b68-c61e-57cd1ad312e2@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC PSD and non-existent subdomains 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, 11 Jun 2019 16:54:39 -0000 On 6/11/2019 11:38 AM, Alessandro Vesely wrote: > On Tue 11/Jun/2019 00:41:16 +0200 Scott Kitterman wrote: >> On Monday, June 10, 2019 8:07:25 AM EDT Richard C wrote: >> >>> Presumably other PSDs that aren’t brand new will have this problem too? I’m >>> interested to hear whether we’re on our own or not. >> >> As written, DMARC (RFC 7489) has the option to express different policy for >> subdomains (sp= tag). Perhaps we could address this case in PSD DMARC by >> leveraging that feature. >> >> PSD DMARC is the first time there is any DMARC related explicit guidance on >> non-existent sub-domains. If we made it a rule that non-existent sub-domains >> use the domain level (p=) policy and existent sub-domains use the sub-domain >> policy (sp=) then I believe the affect you are after is achievable. > > > Rather than altering p= and sp=, I'd add an np=, say, for non-existing domains: > > * It certainly would gather more attention by implementers, > > * Domain owners could monitor to check it. > > * It allows the main domain to have a non-reject policy. +1. I like this. In general, I want compatibility, but it seems, in my opinion, to be a lack of willingness to consider more tags. Maybe it is a messenger problem, but we long had quite a number of extended ideas for a standard DKIM Policy protocol framework. The Domain Discovery Lookup Method is one of them and its directly and indirectly related to 3rd party policy concepts, one that is defined by some public suffix list where I am not familiar with, appears to had politics involved too, and off hand, it appears to have a trust factor. Can I trust using this list? Where do I get this list? Is there are periodic update concept and so forth. I will place my trust on the cogs with this, but at this point, I will note I am lost with the extended logic algorithm being proposed. Trying the fast read the draft specs does not help. Maybe Scott can describe it (extended Lookup method) in pseudo code. -- HLS From nobody Tue Jun 11 10:01:39 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1649B12011E for ; Tue, 11 Jun 2019 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmPLYaz_L1eJ for ; Tue, 11 Jun 2019 10:01:35 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9AB5120129 for ; Tue, 11 Jun 2019 10:01:34 -0700 (PDT) Authentication-Results: mail.aegee.org/x5BH1UT7004322; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1560272492; i=dkim+MSA-tls@aegee.org; r=y; bh=Lgkg2RK1IjRZKChMQyUtFU01UAst3rfnych7Sn0Jz4A=; h=Subject:From:To:Date:In-Reply-To:References; b=IRCam95cH/fKM/iNIhBdpIr5yJh97rO7dQZw52MzAitsq2gd0vL5kwxMhyE4JdTZq QFOJ/la65TozikMPgmV8mlaX/Ck7Fh6AloEsXxqxr6Ixkyq8Q39OVlyBRVo+DtQx1e 4i9ICmZnOwSXlnjTXiYHucUnmZH3ja1A33+b93sdrXTaVQhiN4wRAD0Sd8/pa7Esok o/HjvEx1/9zxyMhc/182rPiNy8ET/9ajLFIS42MWICckro0I8+lqq/SYYADTKXZyR3 h/V1XhjxHSTSTL2rd/Fg2OU1zk1SjBBXLmEPqURbSqntCu3Zt4ruoY62QwICOiGe3t l8wdN3GmPKY/jDV8sASO2Mq/+5KEU0uAdjRTz9soBkBqCTf5Q7kqeQjx1UCeg8u6j8 rGpn1eSvx7JX6jDhbpxLEMWi/+fRt6JsZrz0arl9FYUM20q9y1wItmrdxkfRYkxYfp mfAkFUgrHIUQPz+zS26PVAuXHDzEub+lDRmAm9zWNntH2hUoeB7ZAfQYqWIlbagDAx E8nu2Ws8aKKr5L/LaAlQ7DvE2hRCqrhqvSBNYNRsrnjDMI9I3tVOto5ASNX+JIOpCp NxWcc58cN0bv6p7sysvAzNfUeB0KXCHBGoKfLTLRvLJ+K5pobEd1ptvqXraqGDCIZj Owt/cfE/O6cMu265+kqrvLAo= Authentication-Results: mail.aegee.org/x5BH1UT7004322; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5BH1UT7004322 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Jun 2019 17:01:31 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Alessandro Vesely , dmarc@ietf.org Date: Tue, 11 Jun 2019 17:01:30 +0000 In-Reply-To: <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 11 Jun 2019 17:01:37 -0000 Hello Alessandro, > I'd propose bullets like the following for Section 12.4: > o The authentication status of the message should be visible. > For DMARC policy reject, the failed status will not be visible in the MUA, because the mail will not reach the recipient. Likewise for the policy quarantine, because this policy means “do not deliver” (and do not reject, but do something different). So if the DMARC evaluation status for policies Quarantine or Reject is shown, it will be PASS. For policy None, I doubt that showing the authentication status has added value. So if the MUA shows the status for DMARC it will be PASS. When will showing the DMARC status to the user have added value for her? For SPF status... you know that redirects, if the MUA shows “failed SPF”, what shall the user conclude? For DKIM evalution, that was not covered by the DMARC policy above, you suggest that the MUA shows "DOMAIN: FAIL/PASS". If it passes, then it is good. But what shall be the conclusion made by the user, if the DKIM for a domain shows FAIL (or missing DKIM-Signature header)? Regards Дилян From nobody Tue Jun 11 10:29:02 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B5D120098 for ; Tue, 11 Jun 2019 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 iRHONgkgKZww for ; Tue, 11 Jun 2019 10:28:59 -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 32FE9120094 for ; Tue, 11 Jun 2019 10:28:59 -0700 (PDT) Received: from [192.168.1.87] (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 x5BHV9ah010122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Jun 2019 10:31:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1560274270; bh=Unkl089PeM0ShsD5uMAQAp8GsOOzCrtQ8QTzp+x6rH0=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=NL47V9ivTpGNLBHyRqu2/jvsaIhzchoovQ5CMGOu2ZCuCjOLAT0jrojIN4TGpANwO lXGylcvGN7tV+mw1zdHWnLkf8jzG7fJWeINvXrdv9Qy8XNrMgBME4Es1jgWPrBGevw mygy/RNf2nlTpTwIoiMDJzFxMkzgGGq9SRKDIz3c= To: Alessandro Vesely , dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> Reply-To: dcrocker@bbiw.net From: Dave Crocker Message-ID: <98411dd3-b22e-9893-94a7-0f3d3eafa5d7@dcrocker.net> Date: Tue, 11 Jun 2019 10:28:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 11 Jun 2019 17:29:01 -0000 On 6/11/2019 8:12 AM, Alessandro Vesely wrote: > On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote: >> On 6/10/2019 1:17 AM, Alessandro Vesely wrote: >>> On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: >>> >>>> Except that most users don't actually see that address because these days most >>>> MUAs only display the display address. >>> >>> >>> We often came across this realization.  Since DMARC hinges on that field, I >>> think the spec should include some advice to MUA implementation. >> >> Unfortunately there is no 'advice' to give that has any utility. >> >> If you feel otherwise, please try to formulate it, including the basis for >> believing it useful, and then try to get community support for it. > > > I'd propose bullets like the following for Section 12.4: > > o In the MUA, it is safe to only show the display name if its Sorry, but I asked for evidence of utility. My guess is that you are only thinking in terms of information theory, rather than human factors usability. These produce very, very different results. To my knowledge, there is no empirical evidence at all of what RFC5322.From display strings are safe or dangerous to show. > o The authentication status of the message should be visible. Why? What's your empirical evidence of utility for this? >>> A trust on first use (TOFU) approach would seem to be possible. >> >> In practical terms, what does that mean?  Who does what, exactly? > > > A discrepancy can be enhanced by bold characters, by a pop-up, or by a beep and > an alert message. Anything but silently displaying a familiar name which > actually stands for something else. I suspect you are not familiar with a related effort that was pursued for the web, distinguishing domain names that had ave been vetted vs. those that have not. It did not go well. > A user can then arrange her address book so as to make it clear to the MUA that > a class of email addresses are equivalent to one another, in order to avoid > meaningless alerts. What makes you think users want to do this extra work or that they will. Evidence to date is that they don't and won't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 11 13:08:20 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9C51200B5 for ; Tue, 11 Jun 2019 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=il4WvgzW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ATrUUFNc 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 53Duijxg0WiY for ; Tue, 11 Jun 2019 13:08:17 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EC4120059 for ; Tue, 11 Jun 2019 13:08:17 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3EC5B47B for ; Tue, 11 Jun 2019 16:08:16 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Tue, 11 Jun 2019 16:08:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=UyE2eaBqjs5xE+Wsb/ofjJBHCi1Jukr JpjxMpj9fqbU=; b=il4WvgzWziXPlSsBsSlv6GmzsMN35Nx6sLEVf6vMcexfkiX f81pHHxCSesy7vemIpwn0wBK86ozwP3cznQEBEJrepm38vfbNZFljV1uET4YNW8h jbnlr8p7qaT5yUN0/6c7TVTF6yWdLtkuMmHnQmuMIEnMSs2s5ow+9rfVwD9Pw67K BeCBvPHGYyltKlgn9YI+IVwLijzgj2INSKiDfOUtY0qc121UtqLJNxjcoxYtwzVJ SOPWg8AUqDiy6hMJNUbjLiixt4zrFQuBdgJokIa7O6fZvmUM+INkSG7mJ4NEnwmJ uNbadV6ulSJqNmOyMgRpBU9mmJBjcE1Et4pZZYQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=UyE2ea Bqjs5xE+Wsb/ofjJBHCi1JukrJpjxMpj9fqbU=; b=ATrUUFNcD/0NiZkFSFLQMt k84XbxpjACXJ8jX32FGFPTrEWcSUyjDQRMuJWFSuOSPualTdZuJrKyD/7vctlLSn NTRoQlqiBeAYU2JcZXnpNXam/LfbLtQJAHJUPs+JkRscmbHtfb+FLcYjZqahXOlj QLarLclReHBKOZq9ZQEpNV8vlWcVkFowhldBAmk8cPIpliwCI68KFYMrT/ei2BGI H4qHLovZ5/5BHHHGjMZUUChpEoHa1XX2JROEht9lAmYS9JFOcI5hIdkfQ0P0639m 5DItlrgI9Vb8MSaxA50Lx1okA7tn0Z350WrQO5UHm3IdKA8PFovcr79Eb1gKgdIw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehhedguddvlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdfuthgrnhcumfgrlhhishgthhdfuceoshhtrghnsehg lhihphhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvtheqnecurfgrrhgrmhepmhgrihhlfh hrohhmpehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 636291400A0; Tue, 11 Jun 2019 16:08:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: <59cb3de1-b9a6-4fff-a9e5-9e9bf9f832b0@www.fastmail.com> In-Reply-To: <98411dd3-b22e-9893-94a7-0f3d3eafa5d7@dcrocker.net> References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> <98411dd3-b22e-9893-94a7-0f3d3eafa5d7@dcrocker.net> Date: Tue, 11 Jun 2019 16:08:14 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=08c95eac449240b6a34761d306a8df4b Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 11 Jun 2019 20:08:19 -0000 --08c95eac449240b6a34761d306a8df4b Content-Type: text/plain On Tue, Jun 11, 2019, at 1:29 PM, Dave Crocker wrote: > > A user can then arrange her address book so as to make it clear to the MUA that > > a class of email addresses are equivalent to one another, in order to avoid > > meaningless alerts. > > What makes you think users want to do this extra work or that they will. Yes. Users have to be 1) made aware of an argument in favor of the extra work in the first place and, and, 2), after that, convinced of that argument in favor of the importance of that extra work. Like it or not, they're not. I mean, I'm just imagining a stay-at-home parent with three kids who only knows their phone is beeping at them while they're trying to get said kids into the car to go to urgent care because one is throwing up. The beeping is just going to make them mad and you're not even going to make it past step 1. > Evidence to date is that they don't and won't. Indeed. Stan --08c95eac449240b6a34761d306a8df4b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Jun 11, 2019, at 1:29 PM, Dave Crocker wrote:=
> A user can then arrange her address book so as to make it c= lear to the MUA that
> a c= lass of email addresses are equivalent to one another, in order to avoid=
> meaningless alerts.
=

What makes you think users want to do this extra work or tha= t they will.
Yes.  Users have to be 1) = made aware of an argument in favor of the extra work in the first place = and, and, 2), after that, convinced of that argument in favor of the imp= ortance of that extra work.  Like it or not, they're not.
=

I mean, I'm just imagining a stay-at-home parent with three kids w= ho only knows their phone is beeping at them while they're trying to get= said kids into the car to go to urgent care because one is throwing up.=  The beeping is just going to make them mad and you're not even go= ing to make it past step 1.
<= br>
Evidence to date is that they don't and won't.

Indeed.

<= div style=3D"font-family:Arial;">
Stan
--08c95eac449240b6a34761d306a8df4b-- From nobody Tue Jun 11 14:01:00 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C72C1200B3 for ; Tue, 11 Jun 2019 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QQyO7iS5pAF for ; Tue, 11 Jun 2019 14:00:55 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2445D12004A for ; Tue, 11 Jun 2019 14:00:54 -0700 (PDT) Authentication-Results: mail.aegee.org/x5BL0pU1009483; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1560286852; i=dkim+MSA-tls@aegee.org; r=y; bh=Wq5hiVKEbj8yE4q+RxjSXLDyoCQKUWYWx1UmESeEkcc=; h=Subject:From:To:Date; b=BSR/0BpYwMDHs231PMY1jUHzD8Kz8RnLeHaJwuqx4VgGhbloa3tJwe/+YT/66qqr9 iwE8ZaoljjRKQ3FHi5Vcdl0kG9tN4q/vzF0RlIdUksM80SOryzRCohQnyECL8SPz+6 GFjnvwhYTIIcIgap0/wRf00Cy8O5WDnTsCwm/KMNrszNLkCOxVGGSSI7usrNn62t9b yFVtv7c/U5JGBPaBo4C27vMnlsKHvxggGIm/iTh1/ZZZnycpon7vr3ZxO4FpIGWUjl 3DQjn9WNk5pVOrFdrIMdyk+b+WIkqFh8YaXHd2nIioTv/b9MxqzU1vrLqijyVbsatx QICPZ4qpNBNvfXLUow6xbkgHyySxqCDJQPSqxDtuxs+RWcDQzreUKoSw2Huk85HsSK 8KPajVfN+3SS79geq8aconVexfs8gZJGSBxiSukl5FlAixQsaeoaOgWh0CExSIfx5x 9U7CTgbHLxgu1pBPfLxGJhFUNG8PyzCxvFw5lrf6hZrFZGNKS3dZzpQRXnSBndJ+Ea 1n+Vbsl2G91Ne0y0c1FAkvvnWu3juO1jjOmvbKuBOo9qoD91Bl/ktYVkKxAtJbq+Jm 3erGOCLqdTKpQ3B6/jfQOHK0TW1y11HkDE3BRomTMXyNFO/UdnAxA/HDseYEcRPQg4 RjvTr4cMOMr7ctYeaUEdX9qI= Authentication-Results: mail.aegee.org/x5BL0pU1009483; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5BL0pU1009483 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 11 Jun 2019 21:00:52 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: dmarc@ietf.org Date: Tue, 11 Jun 2019 21:00:51 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 11 Jun 2019 21:00:57 -0000 Dear all, when DMARC passes, there is no difference between p=reject and p=quarantine. When DMARC fails validation, this means extra work for humans. This work can be done by the sending or by the receiving organization. With p=quaratine, the sending organization (domain owner) indicates, that the extra work is supposed to be done by the receiving organization. So for the senders it is just cheaper (in terms of less work) to publish p=quarantine. With p=reject, the sending organization (domain owner) indicates, that the extra work has to be performed by the sending server, which might be the domain owner or some suspects. However, it is ultimately up to the receiving site to decide, whether it wants to accept this extra work. If it does not accept the extra work, it just handles quarantine as reject. This does not violate the DMARC specitification. Do you have a story, why one wants to publish p=quaratnine? What is the use case for it? It just makes emails less reliable, as they end as Junk and this is very similar to discarding the emails. Imagine a mailing lists, where the recipient of an email address expands to several mailboxes on different domains. An incoming email fails DMARC validation before being distributed over the ML. The domain owner for that mail origin has published p=quarantine, this email cannot be delivered in the Junk folder of the recipient, because the mailing list itself does not have a junk folder. How about, deleting policy Quarantine and instead rephrasing policy Reject: It is up to the receiving server if it rejects messages failing DMARC, or accepts and delivers them as Junk. (This does not change the protocol, just the wording) Regards Дилян From nobody Wed Jun 12 01:54:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E7B1200C5 for ; Wed, 12 Jun 2019 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL3ScMWpDIbR for ; Wed, 12 Jun 2019 01:54:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BBA1200BA for ; Wed, 12 Jun 2019 01:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560329686; bh=bNc0CJ34OuMWjICzpOh4ujbjkNcUyzbzPjHU7C81G5A=; l=1790; h=To:References:From:Date:In-Reply-To; b=AYrRlbQx2DXvj2OM5mpUPyZzxsdq21KIs1DD/O09noSfOpEK65OHfs52IxfkUf3gm JFI6LIfwMNYfEU5egLPg7seYlu0sdkLXfyFJ8FqcGmTZ3lSXorTRser8uUpJE2t0sG FHGpuucmk+MsN90XXpCs+rQcfrwcceGRCQb+N5T2UJBBPkbkHBnhpnoYvm2zF Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 12 Jun 2019 10:54:46 +0200 id 00000000005DC02F.000000005D00BDD6.00003B78 To: dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> <5CFFD8F7.9030109@isdg.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Wed, 12 Jun 2019 10:54:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5CFFD8F7.9030109@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 12 Jun 2019 08:54:50 -0000 On Tue 11/Jun/2019 18:38:15 +0200 Hector Santos wrote: > On 6/11/2019 11:12 AM, Alessandro Vesely wrote: >> >> Section 12.4 seems to have some problems.  The first bullet should be reworked, >> because it can be understood as suggesting that in cases like, for example: >> >>      From: "user@example.org via Bug Tracker" >> >> a _MUA_ should "execute the DMARC mechanism on the domain name found there >> rather than the domain name discovered originally."  That sounds nonsense, >> first, because MUAs should rather base on A-R records added by the MX. > > This is what I meant above.  You are proposing a trust concept for the MUA on > which A-R record to "believe." > > The MUA needs trust on the meta-data headers it sees.  In theory, it could > trust (with higher confidence) the headers added by the user's mail hosting > provider or the server the user logged into, or basically the last processing > machine at the hosting provider. > > Maybe Murray can comment on this, I don't recall seeing a discussion where the > A-R verifying.domain was tied to some trusted hosted domain we have confidence > in.  Can the MX or MDA domains be associated with the A-R verifying the domain? To verify domain hierarchy might be possible, but cumbersome. Section 1.6 of the rfc says "valid use of the header field requires removing any occurrences of it that claim to be associated with the ADMD". IMHO that is the minimal requirement. I find it handy to remove /all/ existing A-R fields[*]. That way, you can tell the MUA to just trust A-R in the messages retrieved from such account. [*] Actually, the server renames them Old-Authentication-Results, so they're visible when you manually watch the headers. Best Ale -- From nobody Wed Jun 12 01:58:13 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3695B12010F for ; Wed, 12 Jun 2019 01:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IapIHc1LbGmL for ; Wed, 12 Jun 2019 01:58:09 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBA21200C5 for ; Wed, 12 Jun 2019 01:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560329887; bh=giMUSz7748KFdN9WpPsOnzFxNNJEp2LPaWPa51+hl7Q=; l=3187; h=To:References:From:Date:In-Reply-To; b=DjqV9Uq6Mc+w1ZCXUeLlbYZ1RwZrAWjj1bFuVUIRMk1Ba68F+0KkUkJw1caCU2IKl VGuCJmTSVFObBJSzgxD5hb32nXZwsTjcitjdRBdBM/cOUpan9d98F8NjbuGVFd7z27 XLGoLJoFU/3teS2k9IrW1WDCKAiQCvXctYqZWuDdqZRbVal6RB2NLzlTps3Y8 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 12 Jun 2019 10:58:07 +0200 id 00000000005DC02F.000000005D00BE9F.00003BD6 To: dcrocker@bbiw.net, dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> <98411dd3-b22e-9893-94a7-0f3d3eafa5d7@dcrocker.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Wed, 12 Jun 2019 10:58:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <98411dd3-b22e-9893-94a7-0f3d3eafa5d7@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 12 Jun 2019 08:58:11 -0000 On Tue 11/Jun/2019 19:28:58 +0200 Dave Crocker wrote: > On 6/11/2019 8:12 AM, Alessandro Vesely wrote: >> On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote: >>> On 6/10/2019 1:17 AM, Alessandro Vesely wrote: >>>> On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: >>>> >>>>> Except that most users don't actually see that address because these days >>>>> most MUAs only display the display address. >>>> >>>> >>>> We often came across this realization.  Since DMARC hinges on that field, I >>>> think the spec should include some advice to MUA implementation. >>> >>> Unfortunately there is no 'advice' to give that has any utility. >>> >>> If you feel otherwise, please try to formulate it, including the basis for >>> believing it useful, and then try to get community support for it. >> >> >> I'd propose bullets like the following for Section 12.4: >> >>      o  In the MUA, it is safe to only show the display name if its > > Sorry, but I asked for evidence of utility.  My guess is that you are only > thinking in terms of information theory, rather than human factors usability.  > These produce very, very different results. > > To my knowledge, there is no empirical evidence at all of what RFC5322.From > display strings are safe or dangerous to show. I relied on the exception raised in the first quote above. Actually, the reason why DMARC requires alignment of SPF identifiers is because "These may be different domains, and they are typically not visible to the end user."[*] If the RFC5322.From domain is also not visible to the end user, that argument is moot. Yes, that's just theory... [*] Section 3.1. Identifier Alignment >>      o  The authentication status of the message should be visible. > > Why?  What's your empirical evidence of utility for this? Well, I personally use it and sometimes find it useful.[†] For a better statistics, I have a DKIM add-on whose purpose is just to display some authentication status. With 10,107 users, it ranks 61st of 1,339 in Thunderbird's most popular extensions. [†] I tag _nopass_ messages not matching /^Authentication-Results:.*pass/ and color them gray in the thread pane. Many of them can be deleted w/o opening. (But then I have more pass'es than DMARC provides for.) >> A user can then arrange her address book so as to make it clear to the MUA that >> a class of email addresses are equivalent to one another, in order to avoid >> meaningless alerts. > > What makes you think users want to do this extra work or that they will. > Evidence to date is that they don't and won't. I imagined the MUA would prompt the user something like so: __________________________________________________ | | | "John" appears to be the same in | | | | , , | | and 23 other addresses. | | _ | | [_] They're all the same person | | [_] Always display the address of "John" | | | | | | [ FRAUD ] [ OK ] | |__________________________________________________| The user can thus arrange the address book with two clicks. Would that work? Best Ale -- From nobody Wed Jun 12 01:58:54 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA80D1200C5 for ; Wed, 12 Jun 2019 01:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtT-S6JEcuMu for ; Wed, 12 Jun 2019 01:58:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FBA12010F for ; Wed, 12 Jun 2019 01:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560329922; bh=UV/O75goVT84oqngZyc5vn73iIcmbp7hMNPC76a5L6w=; l=249; h=To:References:From:Date:In-Reply-To; b=CSDYgU1nSLzMNnUJnj1HZlb8zCIpJjPIOEJkyk+IatyJ/MvWaC9HfWHS+Do+ZT1pp WPBKAWM1WdQYz8PCWYUme6RY6KWmyldF2zGNRu26jL2NEe3QbZE2WyJPRgS1VD4odf y2aV+QBFv5619wkcp/sFoqhdMyF+t8tPUZK3ruvc6AzhIEWjUZY/rec8GWywe Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 12 Jun 2019 10:58:42 +0200 id 00000000005DC084.000000005D00BEC2.00003BFE To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , dmarc@ietf.org References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <2128b73d-0d9a-3007-ce35-02b928847332@tana.it> Date: Wed, 12 Jun 2019 10:58:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 12 Jun 2019 08:58:46 -0000 On Tue 11/Jun/2019 19:01:30 +0200 Дилян Палаузов wrote: > So if the MUA shows the status for DMARC it will be PASS. If there's nothing but DMARC-validated messages, then the spec can't get any better than that. Best Ale -- From nobody Wed Jun 12 02:14:31 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E3512010F for ; Wed, 12 Jun 2019 02:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0YYti3smQpR for ; Wed, 12 Jun 2019 02:14:26 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 55A8C120077 for ; Wed, 12 Jun 2019 02:14:26 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id n189so9442660itd.0 for ; Wed, 12 Jun 2019 02:14:26 -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=dFLXLEQgopFDvr6ha9bXJTcES+JWf922aAwPspoOkwA=; b=VVx/Gizue+KTXKx3OOfCY1v3bVdd5fZz9P8K+hKwhVJn7oh+bE6AE1zJX3JMseqnkP IAYI2j08xnesxla4rWwKT88DxK6dxb+Grr5dt/H3Q1iWkgLYUSVS0tr1DD9OtnDxpqkM fBSz9ITNoU+657aphOy+4V8Oet213+3QNCA/I= 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=dFLXLEQgopFDvr6ha9bXJTcES+JWf922aAwPspoOkwA=; b=XORgpnnsxXAj9b/GnVSQoRgSaTkSqw0EzRJiN+VfkSc346wJuuiB43A8BCesRVhZ7z omT2NmyFabp7+K9eI7PuLN4FSz8uzTJVYmnkWvHaJl1Aa7ZfvkFQKOmrflCoRIjdNtJg 4pIpMNWKcNphi4GIPVjc2U53DCMfWSNzO4FBedYX20ARJ1XT7KMxGbMPiWePsTbnkicG ievX+IgEPQdM8T+hoHCVR7vHYpmQ5rvYjSd5l4KihfcDfWhOZYlx75qL87BzHti9v+bB cqab5H8FGu/5LhxZwO2w44HTavKKD9vS4DFw+bTOHmSvQVKerJgxIhngJCdHrNXbjan1 m69w== X-Gm-Message-State: APjAAAU29c0JxF4kMIgBSyUyCWrQYd/z1nXdUUpp7VBMFEwpsQurR8Te G4pNm6vtJwgR7dQZHQIUNyqaQAxaigs/EHh72ZBgBpRNhFdwQ/I2 X-Google-Smtp-Source: APXvYqzXqTl6tCY3toC4+biYiEPk558e/CCBXQw5UakGes4Bb18ll13nya+4ET890m6wdf3ssmALjZ+Ygm7q1qbIQ/Q= X-Received: by 2002:a24:504b:: with SMTP id m72mr20710511itb.63.1560330865397; Wed, 12 Jun 2019 02:14:25 -0700 (PDT) MIME-Version: 1.0 References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> <98411dd3-b22e-9893-94a7-0f3d3eafa5d7@dcrocker.net> In-Reply-To: From: "Kurt Andersen (b)" Date: Wed, 12 Jun 2019 17:14:13 +0800 Message-ID: To: Alessandro Vesely Cc: Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6ebf7058b1cd69a" Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 12 Jun 2019 09:14:29 -0000 --000000000000f6ebf7058b1cd69a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 12, 2019 at 4:58 PM Alessandro Vesely wrote: > > Well, I personally use it and sometimes find it useful.[=E2=80=A0] For a= better > statistics, I have a DKIM add-on whose purpose is just to display some > authentication status. With 10,107 users, it ranks 61st of 1,339 in > Thunderbird's most popular extensions. > > [=E2=80=A0] I tag _nopass_ messages not matching /^Authentication-Results= :.*pass/ > and > color them gray in the thread pane. Many of them can be deleted w/o > opening. > (But then I have more pass'es than DMARC provides for.) > Are you suggesting that you are a good proxy for a "typical" user of any random MUA? Incredulously, Kurt --000000000000f6ebf7058b1cd69a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 12, 2019 at 4:58 PM Alessandr= o Vesely <vesely@tana.it> wrote= :

Well, I personally use it and sometimes find it useful.[=E2=80=A0]=C2=A0 Fo= r a better
statistics, I have a DKIM add-on whose purpose is just to display some
authentication status.=C2=A0 With 10,107 users, it ranks 61st of 1,339 in Thunderbird's most popular extensions.

[=E2=80=A0] I tag _nopass_ messages not matching /^Authentication-Results:.= *pass/ and
color them gray in the thread pane.=C2=A0 Many of them can be deleted w/o o= pening.
(But then I have more pass'es than DMARC provides for.)

Are you suggesting that you are a good proxy for a &qu= ot;typical" user of any random MUA?=C2=A0

Inc= redulously,
=C2=A0 Kurt=C2=A0
--000000000000f6ebf7058b1cd69a-- From nobody Wed Jun 12 03:15:56 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8551D1201CF for ; Wed, 12 Jun 2019 03:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEAYPK8HaC1L for ; Wed, 12 Jun 2019 03:15:46 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5F81201D9 for ; Wed, 12 Jun 2019 03:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560334543; bh=5SlcFAtcCbbmW5sTQ3ijMsQauttRVnDo0N8Z9eMFBwA=; l=1008; h=To:Cc:References:From:Date:In-Reply-To; b=CYgqQ6d2QJuILZmn1aO7SDjrMOd/3llXUuxi+pgwjZTaxthjm5aRKmwPIfzRR1JtG Q0VqMvGqO/7iQPS31iPM7xPsTcnVPjAicnQCcmXnD0hdeQC6B6cPJbyo9IoYQaqaIu WrnriRP7wKrOmZABN/ghS3QmVUT27rMwbTooOalmMXnMhIiKPe8be5uOZI6Ty Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 12 Jun 2019 12:15:43 +0200 id 00000000005DC077.000000005D00D0CF.00004711 To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , Dave Crocker References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it> <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net> <7f8692bb-6b80-455e-f030-731f3ae36b58@tana.it> <98411dd3-b22e-9893-94a7-0f3d3eafa5d7@dcrocker.net> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <03e6a6d5-542b-f437-0422-89e9f85e60b0@tana.it> Date: Wed, 12 Jun 2019 12:15:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication 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, 12 Jun 2019 10:15:55 -0000 On Wed 12/Jun/2019 11:14:13 +0200 Kurt Andersen (b) wrote: > On Wed, Jun 12, 2019 at 4:58 PM Alessandro Vesely > > > Well, I personally use it and sometimes find it useful.[†]  For a better > statistics, I have a DKIM add-on whose purpose is just to display some > authentication status.  With 10,107 users, it ranks 61st of 1,339 in > Thunderbird's most popular extensions. > > [†] I tag _nopass_ messages not matching /^Authentication-Results:.*pass/ and > color them gray in the thread pane.  Many of them can be deleted w/o opening. > (But then I have more pass'es than DMARC provides for.) > > > Are you suggesting that you are a good proxy for a "typical" user of any random > MUA?  Ten thousand users are certainly more typical than me. Yet, it might be interesting to know how we —the community discussing and implementing email authentication— are actually using it in our own email accounts. Do you see the authentication state of this message? Best Ale -- From nobody Wed Jun 12 04:05:38 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB70120155 for ; Wed, 12 Jun 2019 04:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wemonitoremail.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 6sgKTMWg6vel for ; Wed, 12 Jun 2019 04:05:35 -0700 (PDT) Received: from email.wemonitoremail.com (email.wemonitoremail.com [78.47.26.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9560120150 for ; Wed, 12 Jun 2019 04:05:34 -0700 (PDT) Received: from localhost [127.0.0.1] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1560337532; bh=kF0PEixHs0z9xVUmmcfFMZPLO/dfbi+otRjRNQMnnTw=; h=Subject:From:To:Date:In-Reply-To:References; b=aYWI0FUkBdrYG6/agL5U5hnU9ytC7/+pN69565LvQhwGvjlnf1LDHrS5ANABzM5pN 1JoayLm7uA5E83UjvYRCi+nDLk16W3ukSm29KcVV4OSKsQrO6KJXZtAqYeQL8FYroT YeYtZMaII/NSiuBLldYvEVpkWWiu3wZlxywWpo3E= Message-ID: From: Ken O'Driscoll To: dmarc@ietf.org Date: Wed, 12 Jun 2019 12:05:30 +0100 In-Reply-To: References: Organization: We Monitor Email Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at email.wemonitoremail.com X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 12 Jun 2019 11:05:37 -0000 On Tue, 2019-06-11 at 21:00 +0000, Дилян Палаузов wrote: > Dear all, > > when DMARC passes, there is no difference between p=reject and > p=quarantine. [...snip...] > However, it is ultimately up to the receiving site to decide, whether it > wants to accept this extra work. If it does not accept the extra work, > it just handles quarantine as reject. This does not violate the DMARC > specitification. Even in a moderately complex spam filtering engine, DMARC is just one indicator / signal amongst many. Who does the "extra work" is subjective. For example, a large mailbox provider may consider support queries about missing or rejected emails as unwanted "extra work" etc. DMARC does not live in isolation - it's part to a greater ecosystem. > Do you have a story, why one wants to publish p=quaratnine? What is the > use case for it? It just makes emails less reliable, as they end as Junk > and this is very similar to discarding the emails. There is a world of difference between requesting that a recipient flag an incoming message as spam as opposed to asking them to discard it outright. And that is regardless of how individual mailbox provides treat p=quarantine. A use case for p=quarantine is that when deploying DMARC for any reasonably complex site, it forms part of a graduated approach (perhaps in conjunction with pct=x) utilising aggregated reports to moving towards p=reject. The proactive nature of DMARC means that its deployment needs to be properly planned with any risks mitigated as best as possible. The various stages of p= can easily be articulated on a project plan / risk register. And such sites that require such planning are often starting from a position of improperly documented mail flows and inconsistently implemented SPF/DKIM. In addition they often operate in regulated sectors and are commonly top-heavy with risk-adverse middle management. I accept that a small site with a simple mail flow which does not operate in a regulated space and has thin governance could likely move straight from p=none to p=reject without serious repercussions. Such sites are not the majority of DMARC deployments. DMARC changes how recipient mailbox providers treat email and therefore it needs to be deployed in a controlled manner, p=quarantine being one component of that. > Imagine a mailing lists, where the recipient of an email address expands > to several mailboxes on different domains. An incoming email fails DMARC > validation before being distributed over the ML. The domain owner for > that mail origin has published p=quarantine, this email cannot be > delivered in the Junk folder of the recipient, because the mailing list > itself does not have a junk folder. DMARC was never originally intended / scoped to work with domains which interacted with mailing lists. The 5322.from address rewriting kludge allows such interaction by removing future DMARC tests. A mailing list operator can also choose to reject emails from domains which have a DMARC record. DMARC has no use case to offer when working with mailing lists. > How about, deleting policy Quarantine and instead rephrasing policy > Reject: > > It is up to the receiving server if it rejects messages failing DMARC, or > accepts and delivers them as Junk. > > (This does not change the protocol, just the wording) I think this is completely unwarranted for (at a minimum) the above mentioned reasons. Ken. From nobody Wed Jun 12 06:28:38 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C581200E9 for ; Wed, 12 Jun 2019 06:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=fUqQVHHj; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=e2P58cJw 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 BjSkz7BirHSV for ; Wed, 12 Jun 2019 06:28:35 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id F2F661200B3 for ; Wed, 12 Jun 2019 06:28:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2172; t=1560346106; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Mx+YeA+g19oD15w7pFPrq34nn5k=; b=fUqQVHHjs1Wn7JqjnqKFgdNXK5VnEHanSSzAsJU7jeQ3X0yT2QfUx4e1wyBxO9 hF0UT1jYJEdHCLOuho10NMLrZQJrCk+VDXPSQomD6GOct9ikE9LM1K5o7rXW5bCA QLcygDjau25HsjDInn0it1kw01ydW4Uo7BSmPqw5pRIpQ= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 12 Jun 2019 09:28:26 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1138545530.1.824; Wed, 12 Jun 2019 09:28:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2172; t=1560345906; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KTKXx7s CreXllXO4ptbBsrIXyeYeDxrY+eBwZ1C8GgA=; b=e2P58cJwMZ9Xf9LJ8UlbJZy RMZsDwVGEoxCfRPgbmnOuyUsi/WB4ezMyYuBOFl78wiWjbcsAP8sBkLMBKYWGw7C Sr2AF0cAIwTQd/BRp5IpD02ef8j/keMQpEYjwOFRLg7EmGFuSXS3/Opjp8savcr1 KccoR9GLlieQ+XsJGR4k= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 12 Jun 2019 09:25:06 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2710761785.9.237068; Wed, 12 Jun 2019 09:25:05 -0400 Message-ID: <5D00FDFA.8040303@isdg.net> Date: Wed, 12 Jun 2019 09:28:26 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 12 Jun 2019 13:28:37 -0000 On 6/11/2019 5:00 PM, Дилян Палаузов wrote: > > How about, deleting policy Quarantine and instead rephrasing policy Reject: > > It is up to the receiving server if it rejects messages failing DMARC, or accepts and delivers them as Junk. > > (This does not change the protocol, just the wording) I think that is how it was thought it would be handled. Don't take "rejection" literally, in fact, it can be a discard concept as well. This is all about local policy. A receiver has the option, based on Local Policy and the implementation software to offer: (o) Reject with 55x before DATA state (_) Reject with 55x after DATA state (allows for collection of payload) (_) Accept with 250 and Discard (_) Accept with 250 and Quarantine Whether systems actually do rejections are not, this has been discussed and debated over the years. But in my view, the thinking has evolved to a realization that dynamic rejections at SMTP are real which complicates DMARC with the presumption the DATA is always received. My take is that early systems always accepted mail because of scale/bulk needs and/or their software didn't yet have dynamic hooking, shimming, spawning, scripting capabilities at the SMTP state points. With the advent of advanced hardware, Dynamic SMTP processing at the state points is a relatively new capability, 10-15 years perhaps, where spawning filters at the state point became feasible with a small sacrifice in SMTP session time increases. We even had the discussions about SMTP idle wait time and even explored the idea of a "Keep Alive" concepts using a heart beat reply code. But it was discovered, back then (10 years?), that not all SMTP clients would not be capable to support a kept alive concept while a SMTP server is processing a transaction. In theory, a SMTP hook has about 5 mins to complete otherwise a SMTP client can time out. The 5 mins for time outs is pretty out-dated so don't be surprise to see SMTP servers lowering it down to a few minutes or less due to SMTP clients not hanging up causing scaling problems. But we do expect the SMTP client to wait 5 mins. :) -- HLS From nobody Wed Jun 12 06:38:00 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEC61200C7 for ; Wed, 12 Jun 2019 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.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 aKVQigbNqx39 for ; Wed, 12 Jun 2019 06:37:57 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id D0D5D1200B3 for ; Wed, 12 Jun 2019 06:37:56 -0700 (PDT) Received: from [192.168.0.227] (unknown [37.228.251.105]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 4D4C99F146; Wed, 12 Jun 2019 06:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1560346675; bh=NDZXzYrX1WXTuLJOtAJHuNVtrIK2PFefTelnzbghm18=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=GJW3i7wtCLZdXN+5ItzA1+I6hDkVZKA8ExJRSupOegB7IHoBuDANKCfHIdgjoURJA 3Ps3i5CviZKSHCkLKp2BKLD9AaeraIrWaZI2K8RfMXoIXA/O+vgvLIK5fFMwylGbeL p3/iEMUx6ChMpWPNf0dnUyXpjieWiRWYfVtf0200= From: Laura Atkins Message-Id: <4B7278AE-7AFC-4183-A879-644D4F9AAB69@wordtothewise.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D24DA5BF-C2A9-4C1A-9BC3-D3E8E3471E3E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jun 2019 14:37:52 +0100 In-Reply-To: <5D00FDFA.8040303@isdg.net> Cc: dmarc@ietf.org To: hsantos@isdg.net References: <5D00FDFA.8040303@isdg.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 12 Jun 2019 13:38:00 -0000 --Apple-Mail=_D24DA5BF-C2A9-4C1A-9BC3-D3E8E3471E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jun 2019, at 14:28, Hector Santos = wrote: >=20 > On 6/11/2019 5:00 PM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0= =B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: >>=20 >> How about, deleting policy Quarantine and instead rephrasing policy = Reject: >>=20 >> It is up to the receiving server if it rejects messages failing = DMARC, or accepts and delivers them as Junk. >>=20 >> (This does not change the protocol, just the wording) >=20 > I think that is how it was thought it would be handled. Don't take = "rejection" literally, in fact, it can be a discard concept as well. = This is all about local policy. A receiver has the option, based on = Local Policy and the implementation software to offer: >=20 > (o) Reject with 55x before DATA state Given that the 5322.from is crucial for DMARC, and the 5322.from is = transmitted after DATA, how can you evaluate DMARC before DATA? laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_D24DA5BF-C2A9-4C1A-9BC3-D3E8E3471E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 12 Jun 2019, at 14:28, Hector Santos <hsantos=3D40isdg.net@dmarc.ietf.org> wrote:

On = 6/11/2019 5:00 PM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0= =D1=83=D0=B7=D0=BE=D0=B2 wrote:

How about, deleting policy Quarantine and = instead rephrasing policy Reject:

It is up = to the receiving server if it rejects messages failing DMARC, or accepts = and delivers them as Junk.

(This does not = change the protocol, just the wording)

I think that is how it was thought it would be handled. =  Don't take "rejection" literally, in fact, it can be a discard = concept as well.  This is all about local policy. A receiver has = the option, based on Local Policy and the implementation software to = offer:

 (o) Reject with 55x before = DATA state

Given that the 5322.from is crucial for DMARC, and = the 5322.from is transmitted after DATA, how can you evaluate DMARC = before DATA?

laura 

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_D24DA5BF-C2A9-4C1A-9BC3-D3E8E3471E3E-- From nobody Wed Jun 12 06:50:15 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E49B1200E3 for ; Wed, 12 Jun 2019 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzx6TAA9jE_l for ; Wed, 12 Jun 2019 06:50:11 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC7212004F for ; Wed, 12 Jun 2019 06:50:11 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id g135so6668260wme.4 for ; Wed, 12 Jun 2019 06:50:11 -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=WOlei1/8fO0f5dQzlNSRKNB2Z3Bp9Q/eu+nvMgzhLfw=; b=iz+TTLo7xRVcRsF3yc4BaZ6LGWJYzkg3Zx5j6cdC+edq00q2G+YEfwnKXXYPl8kjZB xSw2l/MJvOKqtkpFO95IBflaFNXlj9JBTNVg/kmIfTCkIUaPCMot67fTiFNLcSKYZr/H Txj0AT7FhnmQFLD5tHlGTmQIP0pdUC8FQdTHxTMs/F/HbF/w288paxj4tlD2baA5AS0i R6RBPSImjuCYGmvONxER+Umgr73pdB4/+tjXyA8LLrx2EZaBmDKE0NaIw7tuRC7GPBm7 WT1xbfS0hjsz7jv9GCj4MNBfzupS0juFhHyjaIElXBn9o7fszP44w39T6uVtWMDA6WT1 TxSg== 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=WOlei1/8fO0f5dQzlNSRKNB2Z3Bp9Q/eu+nvMgzhLfw=; b=H20A29lsy+yXBV1HNWygsxSyH7dRHlBVGtBolPwih9qN6/JAb5gCtXsiU5hyxB57IL KnHacXwowE5Q4uY83xDa9X86q++AIBduy/vlfUksn/vFeEgnzF8H86rTE47NoEkR9NVT bBPJqLkaRxWRjAv+qf3nkKvIlQ5/BFR4EvjiKtd/RlUfp0Ty+WTdOUJZKEEozBu4rl6N HgjyhXUWHKCKOeUGShV0PAVwZ9TJJCRhuFEDq6kEyopaMLn6Rtcg62sdQF4sqhkjHgmW rNsyOJiMlqQD5GBGR94bCBg6L6XqWNYOVHXeuMkdH4v/qEe4qBwVPEavKnxhiVeVHW8W XOgg== X-Gm-Message-State: APjAAAWmz3ubpUji02r6H99kSGuyNipj5TEqfKgqk1HJyz6kf6QfQC/m dfKvIy9f6BNjOtdJoeCeB/rIZFyYM1bZ4960B2w= X-Google-Smtp-Source: APXvYqyHefUyJnRlzSx1bMnOGFq0WB28eRxykyUJkm++ono589VC36x76DbEFHiwNryKJfhUXPWJq/j1vdoU2Nnr5c4= X-Received: by 2002:a1c:cc02:: with SMTP id h2mr21820112wmb.13.1560347409485; Wed, 12 Jun 2019 06:50:09 -0700 (PDT) MIME-Version: 1.0 References: <5D00FDFA.8040303@isdg.net> <4B7278AE-7AFC-4183-A879-644D4F9AAB69@wordtothewise.com> In-Reply-To: <4B7278AE-7AFC-4183-A879-644D4F9AAB69@wordtothewise.com> From: Dotzero Date: Wed, 12 Jun 2019 09:49:58 -0400 Message-ID: To: Laura Atkins Cc: Hector Santos , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000011941a058b20b1b8" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 12 Jun 2019 13:50:13 -0000 --00000000000011941a058b20b1b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 12, 2019 at 9:38 AM Laura Atkins wrote: > > On 12 Jun 2019, at 14:28, Hector Santos > wrote: > > On 6/11/2019 5:00 PM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB= =D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > > > How about, deleting policy Quarantine and instead rephrasing policy Rejec= t: > > It is up to the receiving server if it rejects messages failing DMARC, or > accepts and delivers them as Junk. > > (This does not change the protocol, just the wording) > > > I think that is how it was thought it would be handled. Don't take > "rejection" literally, in fact, it can be a discard concept as well. Thi= s > is all about local policy. A receiver has the option, based on Local Poli= cy > and the implementation software to offer: > > (o) Reject with 55x before DATA state > > > Given that the 5322.from is crucial for DMARC, and the 5322.from is > transmitted after DATA, how can you evaluate DMARC before DATA? > > You can't evaluate DMARC before DATA. On the other hand, evaluating DMARC is not a MUST for SMTP email. It is at best a SHOULD and more likely a MAY. Speaking as an original participant in the dmarc.org team, we recognized that there was no way to mandate participation in the DMARC worldview and that it would get implemented based on perceived value by both sending domains and mailbox providers. Michael Hammer --00000000000011941a058b20b1b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 12, 2019 at 9:38 AM Laura= Atkins <laura@wordtothewise.= com> wrote:

On 12 Jun 2019, at 14:2= 8, Hector Santos <hsantos=3D40isdg.net@dmarc.ietf.org> wrote:
=
On 6/11/2019 5:00 PM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB= =D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote:

How = about, deleting policy Quarantine and instead rephrasing policy Reject:
=
It is up to the receiving server if it rejects messages failing DMARC, = or accepts and delivers them as Junk.

(This does not change the prot= ocol, just the wording)

I think that is how it was thou= ght it would be handled.=C2=A0 Don't take "rejection" literal= ly, in fact, it can be a discard concept as well.=C2=A0 This is all about l= ocal policy. A receiver has the option, based on Local Policy and the imple= mentation software to offer:

=C2=A0(o) Reject with 55x before DATA = state

Given that the 5322.f= rom is crucial for DMARC, and the 5322.from is transmitted after DATA, how = can you evaluate DMARC before DATA?


You can't evaluate DMARC before DATA. On the = other hand, evaluating DMARC is not a MUST for SMTP email. It is at best a = SHOULD and more likely a MAY. Speaking as an original participant in the dmarc.org team, we recognized that there was= no way to mandate participation in the DMARC worldview and that it would g= et implemented based on perceived value by both sending domains and mailbox= providers.

Michael Hammer
--00000000000011941a058b20b1b8-- From nobody Wed Jun 12 07:06:29 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB24D1200B3 for ; Wed, 12 Jun 2019 07:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=bpny7dj/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=JX5DPS87 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 kWWVYfAz_z8l for ; Wed, 12 Jun 2019 07:06:26 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 18D3D1200A4 for ; Wed, 12 Jun 2019 07:06:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1532; t=1560348381; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Y4Q/tr3ZyyJIY4CtnujQ+/xgkAY=; b=bpny7dj/Jwcu7IywDVZzhOEmjdeNUtA28RLm/0BFn/fEMuCE4THv03r8Sebyrl 6hsc00R/FxaJVkW+fll6ahgYKhIvVnLVBttr2A8P6t0pUEr+LG8a2oO23VtQRbaa ErU9qtoYGNaDQUkHQ01T8J3lIkKLbCBzw77nosDd7bzmM= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 12 Jun 2019 10:06:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1140820586.1.2484; Wed, 12 Jun 2019 10:06:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1532; t=1560348182; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7i4goDA /s6q4Mr4buGO0iFlr4kOsTodIAB44+mA0j6k=; b=JX5DPS87/zUXmp7RpMU0Ff9 DKif2TIKvQOEQy0TXzMC8NxYCWEHGK+I3Sqdcssw1C53vguI2yOzPqUKVy4C9WUI i/zYfmO55OqqhQGrkE4Ww+Wt/AhMXwCx6fCGQWBKHf40IqEjo+9ra6W5FWVjIVh+ xyVqoBi4IQGdpcW6j/EY= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 12 Jun 2019 10:03:02 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2713037598.9.55012; Wed, 12 Jun 2019 10:03:01 -0400 Message-ID: <5D0106DE.6010906@isdg.net> Date: Wed, 12 Jun 2019 10:06:22 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Laura Atkins CC: dmarc@ietf.org References: <5D00FDFA.8040303@isdg.net> <4B7278AE-7AFC-4183-A879-644D4F9AAB69@wordtothewise.com> In-Reply-To: <4B7278AE-7AFC-4183-A879-644D4F9AAB69@wordtothewise.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 12 Jun 2019 14:06:28 -0000 On 6/12/2019 9:37 AM, Laura Atkins wrote: > >> On 12 Jun 2019, at 14:28, Hector Santos >> >> (o) Reject with 55x before DATA state > > Given that the 5322.from is crucial for DMARC, and the 5322.from is > transmitted after DATA, how can you evaluate DMARC before DATA? > When SPF is taking into account. But yes, overall, my comment was more about the whole "rejection" issue whether it was with SPF or with the DATA payload technologies since MARID; SenderID, Domainkeys, DKIM, then ADSP, now DMARC. The "To Reject or Not Reject" question was always there. With SPF and DMARC, for example, if the receiver was made aware of the 5322.From before the DATA state, this would preempt the need to receive the payload in order to get reporting information or perhaps get DMARC overriding deposition, i.e. p=quarantine overrides SPF -ALL rejection. How? Well today, we had the PRA/SUBMITTER protocol used to pass the Purported Responsible Address via MAIL FROM: C: MAIL FROM: SUBMITTER=pra Many clients do use SUBMITTER. Enable it and they will pop up. Since we deprecated submitter when SPF was made standard track, imto, it may be a good idea to explore leveraging this protocol to support DMARC at SMTP. I know this is just an optimization. But I would prefer this optimization over the idea of accepting a potentially large payload of a SPF -ALL failure just to find out if there is a DMARC record because the operator may want to see such SPF only failures. -- HLS From nobody Wed Jun 12 07:41:50 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BCA120123 for ; Wed, 12 Jun 2019 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=C7UDCT67; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=eWnuKapc 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 1yRslxdFjHOV for ; Wed, 12 Jun 2019 07:41:46 -0700 (PDT) Received: from mail.winserver.com (ntbbs.santronics.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id B948212011C for ; Wed, 12 Jun 2019 07:41:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=998; t=1560350501; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=wTZPsOHORlmE5FETJAnDDI1AvvA=; b=C7UDCT673rL+NFr9xSxK/ZajOf5CrIoaXYa9xeJOL1iz7IfDdqZ9t8nmtZ/6+K /Gr/aWnc8XDhYrqCe2tnl+E710ckIg7jGu7KeLmdCyCLiu/8gobaLUj1Zsi498Rg YFUU6tUh3UAXUvnNHsLdKzzp0wwCC4wqZtD5CM3f/AHcE= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 12 Jun 2019 10:41:41 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1142940765.1.5076; Wed, 12 Jun 2019 10:41:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=998; t=1560350304; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nNvhk9p 2DqI5zDM38XXAA/xwf1Pg3f+mLnpoJEWemU0=; b=eWnuKapck+UKrhbP0m+pbNw FzuNYXxQt9E8ZwwLd8FzVwBuwyX93KBf0+xOBB5bFVakrnb1s9EKY5/+eE7/3XmQ GQ1QPq6WM+kkBLijqqA0OxnEUJALwIjhB2QRglb8Df0HAX+7ZYwoqyxHcwSJqvhT X3bRIJ9fdhk44kbuNjro= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 12 Jun 2019 10:38:24 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2715159520.9.44848; Wed, 12 Jun 2019 10:38:23 -0400 Message-ID: <5D010F28.5020506@isdg.net> Date: Wed, 12 Jun 2019 10:41:44 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5D00FDFA.8040303@isdg.net> <4B7278AE-7AFC-4183-A879-644D4F9AAB69@wordtothewise.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 12 Jun 2019 14:41:49 -0000 On 6/12/2019 9:49 AM, Dotzero wrote: > > Given that the 5322.from is crucial for DMARC, and the 5322.from > is transmitted after DATA, how can you evaluate DMARC before DATA? > > You can't evaluate DMARC before DATA. Sure you can. I explained how it can be explored today! Right now, today, it can explored with an existing protocol just was recently made historic: https://tools.ietf.org/html/rfc4405 The status change was done because this protocol was part of the SenderID vs SPF experiment and SenderID lost. SPF was made a standard track protocol. It does not mean we could not consider leveraging the exist SUBMITTER code for other purposes and its a right fit for a high overhead payload technology in DMARC. I will suggest it can offer a high optimization payoff: - Eliminate payload reception overhead, yet still - Provide DMARC reporting and disposition override capabilities. I don't think its an "Horrible Idea." I think its a great idea. :) -- HLS From prvs=060332d33=tki@tomki.com Wed Jun 12 17:27:39 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874891200F9 for ; Wed, 12 Jun 2019 17:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tomki.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 U8HbBWZhJFxK for ; Wed, 12 Jun 2019 17:27:38 -0700 (PDT) Received: from athena.vistabroadband.net (athena.vistabroadband.net [69.39.252.35]) (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 177A9120043 for ; Wed, 12 Jun 2019 17:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomki.com; l=1381; q=dns/txt; s=tomki; t=1560385658; x=1560558458; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; z=Subject:=20Re:=20[dmarc-ietf]=20DMARCbis=20issue:=20Repo rting=20URIs|To:=20Tim=20Draegen=20,=20 John=20Levine=20|Cc:=20dmarc@ietf.org |References:=20<20190527193203.4B74F2014AD9CA@ary.qy>=0D =0A=20<56D45AF9-3C51-46DF-B346-C317B4BAABC5@eudaemon.net> |From:=20Tomki=20|Message-ID:=20|Date:=20Wed,=2012 =20Jun=202019=2017:27:30=20-0700|MIME-Version:=201.0 |In-Reply-To:=20<56D45AF9-3C51-46DF-B346-C317B4BAABC5@eud aemon.net>|Content-Transfer-Encoding:=207bit; bh=hB1Yk+JpE4WpmQvd0x0LsCZds65zgUX04JlHlXnjxZE=; b=ZQsqakriW0sCDkyXRXfQk6Ja9+Brw3JDGyleAPUICLLsqXaPmysRRQ9t M6ZAeQS+s657GZNjCed8LPfcTrBB9lJxyOF72j9n1KT5p2uXQBmzqpl06 YD09HSoOo+T6HZDsD6SqBkp9mECRfoR9dKQg9yZdY4y7z0sphTTg5EMFA C9KMjmOJJZ6IGvWiHEfuZ1K3DW0hkGbG16aDa7jTKpz1M6a1XR1Gk6Vws o3gHrDszZ24NHPfSaDnS1XZTkYTyiFGEODtH2aNoySNBrHZ322dh5qqyc AQfns/5en9K2afEddWvdjKCXCQrIhfSZC/pwC5ewPZ+BdmtxM8e3EpQpf w==; X-Filenames: X-SBRS: -10.0 X-recvListener: Inbound X-sendergroup: RELAYLIST X-remote-hostname: 75-105-60-135.cust.exede.net X-IronPort-AV: E=Sophos;i="5.63,367,1557212400"; d="scan'208";a="44933392" Received: from 75-105-60-135.cust.exede.net (HELO borage.ViaSatDomain) ([75.105.60.135]) by athena.vistabroadband.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2019 17:27:34 -0700 To: Tim Draegen , John Levine Cc: dmarc@ietf.org References: <20190527193203.4B74F2014AD9CA@ary.qy> <56D45AF9-3C51-46DF-B346-C317B4BAABC5@eudaemon.net> From: Tomki Message-ID: Date: Wed, 12 Jun 2019 17:27:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <56D45AF9-3C51-46DF-B346-C317B4BAABC5@eudaemon.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARCbis issue: Reporting URIs 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, 13 Jun 2019 00:36:33 -0000 FWIW (nothing, now?) I'm fairly certain that Netease did have a fully operational implementation of the HTTPS delivery component up until it was removed from the spec. --Tomki On 6/4/19 12:21 AM, Tim Draegen wrote: >> On May 27, 2019, at 3:32 PM, John Levine wrote: >> >> Section 6.3 says that ruf and rua tags can take any URI, but only >> define the meaning of a mailto: URI. Either it should define some >> other URI schemes or it should say that only mailto: URIs are valid. >> >> Back in the olden days there was an http or https scheme that we took >> out because it was ill specified, and nobody but me had tried to >> implement it. If people are interested in an https PUT scheme it >> would be easy enough to define one, but only if someone says they want >> to use it. For large reports it could be somewhat faster than mailto >> both because the report body isn't base64 encoded and the report goes >> straight to the https server and doesn't get relayed as mail does. > > FWIW I've added this to the tracker: > > https://trac.ietf.org/trac/dmarc/ticket/29#ticket > > ...and have mentioned the http POST scheme for TLSRPT. Feel free to add more context if you'd like. > =- Tim > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Fri Jun 14 08:08:15 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9BD120325 for ; Fri, 14 Jun 2019 08:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 3akV24-a-5oL for ; Fri, 14 Jun 2019 08:08:10 -0700 (PDT) Received: from smtp54.i.mail.ru (smtp54.i.mail.ru [217.69.128.34]) (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 E6774120319 for ; Fri, 14 Jun 2019 08:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=U7VZw6l0Lr2EG5j/7dVq4PRatD9cd4TPm9iRN8Xj1OE=; b=C1775hrirtMeGwbh+Gl9KqW4kGmEIT67m51+JU4hDNJmfX3z0aZky2nZVmo5SBlhwxtjxJulvkrYocvulZY/QLzLWT8DnzVcWj6SqS9mcfURwOm3wVw8d6Yz24MHOCOvtg5rnpcYRDQuE1/3nRKWTbtLWv67/KVtpIxd5DaJX4g=; Received: by smtp54.i.mail.ru with esmtpa (envelope-from ) id 1hbnoE-0003RM-GI; Fri, 14 Jun 2019 18:08:06 +0300 To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , dmarc@ietf.org References: From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: Date: Fri, 14 Jun 2019 18:08:04 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: ru Authentication-Results: smtp54.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 897FA1E501F66C9373548B8E9304A8CA4F1B0EDA406CEFA23987E51E3008BF5B X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 14 Jun 2019 15:08:14 -0000 p=quarantine with pct=0 is useful to test DMARC with mailing list/groups which perform "From" rewrite based on DMARC policy. It's safe, because it actually works like "none" but it causes From rewrites, because it's still considered as "quarantine". I would never recommend to use "quarantine" without pct=0, because it can  mask serious deliverability problems. 12.06.2019 0:00, Дилян Палаузов пишет: > Dear all, > > when DMARC passes, there is no difference between p=reject and p=quarantine. > > When DMARC fails validation, this means extra work for humans. This work can be done by the sending or by the receiving > organization. > > With p=quaratine, the sending organization (domain owner) indicates, that the extra work is supposed to be done by the > receiving organization. So for the senders it is just cheaper (in terms of less work) to publish p=quarantine. > > With p=reject, the sending organization (domain owner) indicates, that the extra work has to be performed by the sending > server, which might be the domain owner or some suspects. > > However, it is ultimately up to the receiving site to decide, whether it wants to accept this extra work. If it does > not accept the extra work, it just handles quarantine as reject. This does not violate the DMARC specitification. > > Do you have a story, why one wants to publish p=quaratnine? What is the use case for it? It just makes emails less > reliable, as they end as Junk and this is very similar to discarding the emails. > > Imagine a mailing lists, where the recipient of an email address expands to several mailboxes on different domains. An > incoming email fails DMARC validation before being distributed over the ML. The domain owner for that mail origin has > published p=quarantine, this email cannot be delivered in the Junk folder of the recipient, because the mailing list > itself does not have a junk folder. > > How about, deleting policy Quarantine and instead rephrasing policy Reject: > > It is up to the receiving server if it rejects messages failing DMARC, or accepts and delivers them as Junk. > > (This does not change the protocol, just the wording) > > Regards > Дилян > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru From nobody Fri Jun 14 08:43:06 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3372B120403 for ; Fri, 14 Jun 2019 08:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuXNIML4Naxk for ; Fri, 14 Jun 2019 08:43:02 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 655C11203DB for ; Fri, 14 Jun 2019 08:43:00 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id v14so3035189wrr.4 for ; Fri, 14 Jun 2019 08:43:00 -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=sL1fxIVL1rV5O3gHz8lRLEU5mowtRe0FCocwKJLkmlw=; b=oML/x6WTCtNB1+rT8xtNtjZ5+8F09yKMQ59oV31K6lM2yk5ZMpFriUxgtVMowYH3TZ cR/0tae3ncSW0yehUoKtSf+FsrXdl2QCo9VmztV6iyA9P78RvrsWKo3H1My0FU8i2/ba v2+Do5knxm1yHckDx9ED9yJBGPpHokEEzdLJbVBuEODufU2q6nOr+yO5k0akbWhptSX2 N8zD5LGWXaSkvYuXnCzxavNSUcGjHjMcC0DnrKm9J7YumyZq9ehHQn6JrXybU4mDCTxM kxvdZvZ7GUC7CwO84qFNEHXsXhDnkttx6Xl50EXREo42dH7Ru96oLRKx6Q0ZKQOnzMdZ nkgw== 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=sL1fxIVL1rV5O3gHz8lRLEU5mowtRe0FCocwKJLkmlw=; b=MEhvspYUbfAWON1kQlK5hXEBzIeR92+kXVISVh6opgZsm0chYIcji3J5fu7bYB/Wvc 5IML6zPewu27FDZ45blRRbnOM1uml3OjefjEa41Tg0cUGECordapg89JHb6MWqC7SyUh rk4QbWakLwisYSfyIarTfSrqS5+8iCnN6qsO4FK3lcsrav821p+i9i+afwloj1QPGhvG zuseCLPW2J1lQplzD2dqwX6mYsDGeM5rsvwCgt0ZD/qP/ACrdq1cDk/S26sjB3YMpZp5 C4Feme7enZEjoFX3VOJ8m7MiDkash7Qc01bK5kL+XG5wkjVb5LVfsZIpG3Gm1MwnHZ3I zKzQ== X-Gm-Message-State: APjAAAU1YsIULLlAjDHqV3xBvuAXlWaBi+Xpk2ibuojt/4FCTKzHfPpr o9WQdX9gANYgDcVA28Nh6s5lCvvpIkG0LM2WnlY= X-Google-Smtp-Source: APXvYqxrMNyxkfQoPnPp4pR8+vaQ/DFE4JcTw9p0kxunphFNhFlDWeFmEHtmq/MAoZgWIrwGDnccowZH9kjnUKquF9Y= X-Received: by 2002:a5d:4cc3:: with SMTP id c3mr1235396wrt.259.1560526978974; Fri, 14 Jun 2019 08:42:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Fri, 14 Jun 2019 11:42:49 -0400 Message-ID: To: Vladimir Dubrovin Cc: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003e90bb058b4a8088" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 14 Jun 2019 15:43:04 -0000 --0000000000003e90bb058b4a8088 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 14, 2019 at 11:08 AM Vladimir Dubrovin wrote: > > p=quarantine with pct=0 is useful to test DMARC with mailing list/groups > which perform "From" rewrite based on DMARC policy. It's safe, because > it actually works like "none" but it causes From rewrites, because it's > still considered as "quarantine". > > I would never recommend to use "quarantine" without pct=0, because it > can mask serious deliverability problems. > If the only thing they are using to check deliverability is DMARC reporting, the person has other problems. You should be able to see whether it passed/failed DKIM and SPF but that does not tell you whether it was delivered to the end user (at all) or quarantined in a SPAM folder. Many if not most receiving domains perform all sorts of other checks on incoming mail. Michael Hammer Michael Hammer --0000000000003e90bb058b4a8088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jun 14, 2019 at 11:08 AM Vlad= imir Dubrovin <dubrovin=3D40corp.mail.ru@dmarc.ietf.org> wrote:
=
p=3Dquarantine with pct=3D0 is useful to test DMARC with mailing list/group= s
which perform "From" rewrite based on DMARC policy. It's safe= , because
it actually works like "none" but it causes From rewrites, becaus= e it's
still considered as "quarantine".

I would never recommend to use "quarantine" without pct=3D0, beca= use it
can=C2=A0 mask serious deliverability problems.

If the only thing they are using to check deliverability is DMARC = reporting, the person has other problems. You should be able to see whether= it passed/failed DKIM and SPF but that does not tell you whether it was de= livered to the end user (at all) or quarantined in a SPAM folder. Many if n= ot most receiving domains perform all sorts of other checks on incoming mai= l.

Michael Hammer

Michael= Hammer
--0000000000003e90bb058b4a8088-- From nobody Fri Jun 14 09:25:13 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C91205B4 for ; Fri, 14 Jun 2019 09:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=corp.mail.ru 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 D4TTwNkWmuFk for ; Fri, 14 Jun 2019 09:25:08 -0700 (PDT) Received: from smtp36.i.mail.ru (smtp36.i.mail.ru [94.100.177.96]) (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 01CAF1204EB for ; Fri, 14 Jun 2019 09:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=DoOpLf5z97Y7Q74p1SKGB3GlV6Y0GGpBFXucH+0ccwA=; b=ecBn6XGhSruvrEOrKxsMLxu/432Mx1S4vqO+7JWSso2dsoL45Jhgn1dB7H7Hi6EMulYqSOk5ldOCrRHaLgwBMRoW4E13U6Ks5xYWKVNjVvAytc57Z0dgabtfr0Y35Vd07RWrxVgv9PXyhkIiTYctsP62X3SE0N35MCJBWXuriA8=; Received: by smtp36.i.mail.ru with esmtpa (envelope-from ) id 1hbp0j-0005pz-9L; Fri, 14 Jun 2019 19:25:05 +0300 To: Dotzero , Vladimir Dubrovin Cc: IETF DMARC WG , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD?= =?UTF-8?B?0LfQvtCy?= References: From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> Date: Fri, 14 Jun 2019 19:25:02 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E3333F58A9DF2B87283D112E" Content-Language: en-US Authentication-Results: smtp36.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: D54E4B10AE235269575A2271A8904018BB93280F37F5F2FF3BB6A0B3FC5EE699 X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 14 Jun 2019 16:25:12 -0000 This is a multi-part message in MIME format. --------------E3333F58A9DF2B87283D112E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Nope, I mean 2 different things. 1. Why quarantine is useful (with pct=0).  For example this mailing list (dmarc@ietf.org) performs From rewrite (aka From munging), e.g. dubrovin@corp.mail.ru is replaced with dubrovin=40corp.mail.ru@dmarc.ietf.org. It's because corp.mail.ru has a strict DMARC policy (reject). dotzero@gmail.com is not overwritten, because gmail.com has p=none and ietf.org only overwrites From only for domains with "quarantine" and "reject" policies. It's quite common behavior. If you are implementing DMARC for a new domain (let's say example.org), you usually start with "p=none". With p=none you receive reports for failed DMARC for different lists, like ietf.org. Before switching to stronger policy (p=reject), you may want to know which mailing list will still fail DMARC, and which lists perform From munging and, as a result, do not fail DMARC. For this purpose, before switching to "p=reject" it's useful to switch to "p=quarantine;pct=0". After this, you will only see mailing lists without From munging in DMARC reports. 2. Why quarantine should not be used with pct different from 0 If you start enforsing strong DMARC policy with "p=reject" and you have some previously uncatched misconfiguration (e.g. wrong envelope-from address in some once-in-the-month mailing), you see DMARC failures  in your logs and you can react to this failures and even re-send the messages affected. If you start with "p=quarantine" you have no feedback except reports, and reports are received with a huge lag (up to 2 days) and do not provide sufficient information to catch the exact problem and you can not re-send the quarantined messages. 14.06.2019 18:42, Dotzero пишет: > > > On Fri, Jun 14, 2019 at 11:08 AM Vladimir Dubrovin > > wrote: > > > p=quarantine with pct=0 is useful to test DMARC with mailing > list/groups > which perform "From" rewrite based on DMARC policy. It's safe, because > it actually works like "none" but it causes From rewrites, because > it's > still considered as "quarantine". > > I would never recommend to use "quarantine" without pct=0, because it > can  mask serious deliverability problems. > > > If the only thing they are using to check deliverability is DMARC > reporting, the person has other problems. You should be able to see > whether it passed/failed DKIM and SPF but that does not tell you > whether it was delivered to the end user (at all) or quarantined in a > SPAM folder. Many if not most receiving domains perform all sorts of > other checks on incoming mail. > > Michael Hammer > > Michael Hammer > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------E3333F58A9DF2B87283D112E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Nope, I mean 2 different things.

1. Why quarantine is useful (with pct=0). 

For example this mailing list (dmarc@ietf.org) performs From rewrite (aka From munging), e.g. dubrovin@corp.mail.ru is replaced with dubrovin=40corp.mail.ru@dmarc.ietf.org. It's because corp.mail.ru has a strict DMARC policy (reject). dotzero@gmail.com is not overwritten, because gmail.com has p=none and ietf.org only overwrites From only for domains with "quarantine" and "reject" policies. It's quite common behavior.

If you are implementing DMARC for a new domain (let's say example.org), you usually start with "p=none". With p=none you receive reports for failed DMARC for different lists, like ietf.org. Before switching to stronger policy (p=reject), you may want to know which mailing list will still fail DMARC, and which lists perform From munging and, as a result, do not fail DMARC. For this purpose, before switching to "p=reject" it's useful to switch to "p=quarantine;pct=0". After this, you will only see mailing lists without From munging in DMARC reports.

2. Why quarantine should not be used with pct different from 0

If you start enforsing strong DMARC policy with "p=reject" and you have some previously uncatched misconfiguration (e.g. wrong envelope-from address in some once-in-the-month mailing), you see DMARC failures  in your logs and you can react to this failures and even re-send the messages affected.
If you start with "p=quarantine" you have no feedback except reports, and reports are received with a huge lag (up to 2 days) and do not provide sufficient information to catch the exact problem and you can not re-send the quarantined messages.



14.06.2019 18:42, Dotzero пишет:


On Fri, Jun 14, 2019 at 11:08 AM Vladimir Dubrovin <dubrovin=40corp.mail.ru@dmarc.ietf.org> wrote:

p=quarantine with pct=0 is useful to test DMARC with mailing list/groups
which perform "From" rewrite based on DMARC policy. It's safe, because
it actually works like "none" but it causes From rewrites, because it's
still considered as "quarantine".

I would never recommend to use "quarantine" without pct=0, because it
can  mask serious deliverability problems.

If the only thing they are using to check deliverability is DMARC reporting, the person has other problems. You should be able to see whether it passed/failed DKIM and SPF but that does not tell you whether it was delivered to the end user (at all) or quarantined in a SPAM folder. Many if not most receiving domains perform all sorts of other checks on incoming mail.

Michael Hammer

Michael Hammer

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



-- 
Vladimir Dubrovin
@Mail.Ru
--------------E3333F58A9DF2B87283D112E-- From nobody Fri Jun 14 14:58:46 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E2612009E for ; Fri, 14 Jun 2019 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (4096-bit key) reason="fail (message has been altered)" header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-4kbPrj7uN5 for ; Fri, 14 Jun 2019 14:58:42 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E93E120100 for ; Fri, 14 Jun 2019 14:58:42 -0700 (PDT) Authentication-Results: mail.aegee.org/x5ELwNu3011664; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1560549513; i=dkim+MSA-tls@aegee.org; r=y; bh=/BLhdfcjTL6yYeeUlxV8xRNAD1aHNpeNbiuvkaylHh8=; h=Subject:From:To:Date:In-Reply-To:References; b=fifAqyv8dqVEwk7CjVa25kOx/5NmJgFi8tzYqYu1P+mrAgbYKljR/3gE3BDecDY/c HGUsmFLbfyASX7xgfs7ByzEg+jTuj4qICIadJ79Ew31CTPgHP798IsdNK/mkcGE0Gv phwvhD+m4B42Mp9nSimvXn+/LiWesoIlXUN/1ZOKal1J1k39hDIKaEk8KwY/OCh4lp GKGNMyU+ynn9aNytpjcPJ5BR04njuL6+4p4ke/oUr4grJ5Ih9YMpGgIZpV2CMn/KC5 DLKOOqEkxIQkBcosDsf+4TMud/8tU8M7qcY8Upw1xUEuFccpxjoDhS9kPuWiTOF9+N Y1doYkdG4Y4zgJGEA9vC0H47yrtfgbwb8cVHAIpKQxSgP9ivNovJJu4IoGufGK+oxe tjaFCB7wPmPj0aKURjgaZ+wffABVx4bRaUBsT/PGQK8cqZof8d9hokId150ZS5o9uV ruTGeqt2eOkSOcQYl4P1QOQn8qPjAqvbdqExBKQ+H/jKaFCP98I9TXlCpmCFJ7daCq 3XOCq8qBwW6jwLRSGBuEkIvuNg+nwuhpeg0ii4J1mFaGZq7vHIpZD54i1WnJ6c+psO 1pHG6DRBJX67Iu/g9dkx6qJUtKOd6DBDJHhTHTZT53U+aQ+GHTpj5/ameYj4Gl0tSR NOOAlZbxkM6xXuhOJRMupQ7E= Authentication-Results: mail.aegee.org/x5ELwNu3011664; dkim=none Received: from Tylan (x2e722567.dyn.telefonica.de [46.114.37.103] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5ELwNu3011664 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Jun 2019 21:58:32 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: "Ken O'Driscoll" , dmarc@ietf.org Date: Fri, 14 Jun 2019 21:58:22 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 14 Jun 2019 21:58:44 -0000 Hello Ken, effectively I proposed handling p=reject and p=quarantine the same way. Shall I read in your answer, that failed DMARC validation is weighted differently in the overall spam evaluation, for p=reject and for p=quarantine? > A use case for p=quarantine is that when deploying DMARC for any reasonably > complex site, it forms part of a graduated approach (perhaps in conjunction > with pct=x) utilising aggregated reports to moving towards p=reject. There is no ordering between the policies. p=quarantine is not a softer variant of p=reject, it is just different. Switching from Quarantine to Reject is not a graduate approach. But if some subscribers here see it as such, perhaps more discussions are necessary. In the counter example for extra work, having support queries for rejected emails (p=reject) or for emails arriving misteriosly as spam (p=quarantine) is the same amount of support, extra work. Lets have an example for p=quaranite: majordomo@domain is an address where commands are sent and the software receiving the command always sends an answer, even if the command is unclear. An email is sent to majordomo@domain. The sending domain has published policy Quarantine. This address has no spam/junk folder attached to it. The options for an email are: * reject the email during the SMTP dialog * accept the email and let majordomo send an answer to it * arrange a human to decide which emails to discard (handle an imaginary Spam folder for the account). The third option is expensive and causes delays. The second option could send backscatters, so a caution has to be payed when accepting an email. After the total, complex spam evaluation, the spam filter is uncertain if the mail is spam or not. DMARC evaluation on its own fails. Shall the email be rejected during the smpt dialog (handle Quarantine as Reject), shall the email be accepted, or what do you suggest to do? As for pct=0 on there was a discussion on ietf-smtp@ietf.org whether From: shall be rewritten by the MLM on 25-26 Jan 2019 and the outcome is, that the behaviour is unclear (one cannot act wrong by rewriting or not RFC5822.From:). So on pct=0; further ellaboration is necessary. On Wed, 2019-06-12 at 12:05 +0100, Ken O'Driscoll wrote: > On Tue, 2019-06-11 at 21:00 +0000, Дилян Палаузов wrote: > > Dear all, > > > > when DMARC passes, there is no difference between p=reject and > > p=quarantine. > [...snip...] > > However, it is ultimately up to the receiving site to decide, whether it > > wants to accept this extra work. If it does not accept the extra work, > > it just handles quarantine as reject. This does not violate the DMARC > > specitification. > > Even in a moderately complex spam filtering engine, DMARC is just one > indicator / signal amongst many. > > Who does the "extra work" is subjective. For example, a large mailbox > provider may consider support queries about missing or rejected emails as > unwanted "extra work" etc. > > DMARC does not live in isolation - it's part to a greater ecosystem. > > > Do you have a story, why one wants to publish p=quaratnine? What is the > > use case for it? It just makes emails less reliable, as they end as Junk > > and this is very similar to discarding the emails. > > There is a world of difference between requesting that a recipient flag an > incoming message as spam as opposed to asking them to discard it outright. > And that is regardless of how individual mailbox provides treat > p=quarantine. > > A use case for p=quarantine is that when deploying DMARC for any reasonably > complex site, it forms part of a graduated approach (perhaps in conjunction > with pct=x) utilising aggregated reports to moving towards p=reject. > > The proactive nature of DMARC means that its deployment needs to be > properly planned with any risks mitigated as best as possible. The various > stages of p= can easily be articulated on a project plan / risk register. > > And such sites that require such planning are often starting from a > position of improperly documented mail flows and inconsistently implemented > SPF/DKIM. In addition they often operate in regulated sectors and are > commonly top-heavy with risk-adverse middle management. > > I accept that a small site with a simple mail flow which does not operate > in a regulated space and has thin governance could likely move straight > from p=none to p=reject without serious repercussions. Such sites are not > the majority of DMARC deployments. > > DMARC changes how recipient mailbox providers treat email and therefore it > needs to be deployed in a controlled manner, p=quarantine being one > component of that. > > > Imagine a mailing lists, where the recipient of an email address expands > > to several mailboxes on different domains. An incoming email fails DMARC > > validation before being distributed over the ML. The domain owner for > > that mail origin has published p=quarantine, this email cannot be > > delivered in the Junk folder of the recipient, because the mailing list > > itself does not have a junk folder. > > DMARC was never originally intended / scoped to work with domains which > interacted with mailing lists. The 5322.from address rewriting kludge > allows such interaction by removing future DMARC tests. > > A mailing list operator can also choose to reject emails from domains which > have a DMARC record. > > DMARC has no use case to offer when working with mailing lists. > > > How about, deleting policy Quarantine and instead rephrasing policy > > Reject: > > > > It is up to the receiving server if it rejects messages failing DMARC, or > > accepts and delivers them as Junk. > > > > (This does not change the protocol, just the wording) > > I think this is completely unwarranted for (at a minimum) the above > mentioned reasons. > > Ken. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Jun 14 18:41:24 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8131F1200C4 for ; Fri, 14 Jun 2019 18:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5-5IjdoyMhb for ; Fri, 14 Jun 2019 18:41:21 -0700 (PDT) Received: from athena.vistabroadband.net (athena.vistabroadband.net [69.39.252.35]) (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 09F1C120020 for ; Fri, 14 Jun 2019 18:41:20 -0700 (PDT) X-IronPort-DK-Sig: tomki X-IronPort-AV: E=Sophos;i="5.63,375,1557212400"; d="scan'208";a="44961110" X-IPAS-Result: =?us-ascii?q?A2GQ9AAwSgRdAIc8aUtmhgQShD6CXoYdi1xiAYMqln4QL?= =?us-ascii?q?AERAYQoBAKCcksEAgcCAQECDAEBATJQgjoigxkVHiM1AiYCbAgBAYMeggsFq?= =?us-ascii?q?BKBMYh/gTCBDIlAglyBf4E4ineCWJRmlHIJlV0GG5cyhAygFIFnH4FacJQuI?= =?us-ascii?q?oE0AY8xAQE?= X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GQ9AAwSgRdAIc8aUtmhgQShD6CXoY?= =?us-ascii?q?di1xiAYMqln4QLAERAYQoBAKCcksEAgcCAQECDAEBATJQgjoigxkVHiM1AiY?= =?us-ascii?q?CbAgBAYMeggsFqBKBMYh/gTCBDIlAglyBf4E4ineCWJRmlHIJlV0GG5cyhAy?= =?us-ascii?q?gFIFnH4FacJQuIoE0AY8xAQE?= X-IronPort-Anti-Spam-Filtered: true IronPort-PHdr: =?us-ascii?q?9a23=3AItK6Wh2jxdSWt7bBsmDT+DRfVm0co7zxezQtwd?= =?us-ascii?q?8Zse0WK/ad9pjvdHbS+e9qxAeQG9mDurQc06L/iOPJZy8p2d65qncMcZhBBV?= =?us-ascii?q?cuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx?= =?us-ascii?q?7xKRR6JvjvGo7Vks+7y/2+94fcbglUgDexe69+IAmrpgjNq8cahpdvJak2xh?= =?us-ascii?q?bVuHVDZv5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3?= =?us-ascii?q?so5MLwrhnMURGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RT?= =?us-ascii?q?Kv5LptRRT1iikIKiQ5/XnXhMJtkqxVoxyvqBJwzIHIb4+YL+Z+c6HHcN8GWW?= =?us-ascii?q?ZMUMRcWipcCY28dYsPCO8BMP5FoIn4vVQOtwexBQiyC+PzxD9FnWP23ao/0+?= =?us-ascii?q?QiEAHKxhAvH9ULsHnSsd77N78SXPi3waTI1znPcu9a1Dfn5IXJbhwtu+yAUL?= =?us-ascii?q?xwfMfX1EIhDRnKjk+KpozgJz6V0+MNvHWF4Od4TuKvjnInqxl2ojiy2scgko?= =?us-ascii?q?nJiZwRylDD7Sh224E1JceiR050f9GoCpRftyCAOIVrWMwiX29muCE/yrIcuJ?= =?us-ascii?q?67ejAGyJUhxxHBd/yKa4qF7xL5WOqMPTt1hGhpdbOjixqo7EStxO3xWtGx0F?= =?us-ascii?q?lQrypFltfMtmoK1xzW8sWIV/598V272TmT1gDc9P1EIU4vmKrHLJ4hx70wlp?= =?us-ascii?q?sJvUvfGS/2nV36jLWKeUU85uio9+Pnb639ppCCK490ihrzMr8wlcyjAeQ3KQ?= =?us-ascii?q?wOUHKd+eS/zrHs4Ur5QLBShP0sjqbZqIzaJdgcpqOhHgBV15ws6wyjADq90d?= =?us-ascii?q?QXg2UHLFxfdBKAlYjpNAKGHPetAfK2mV+EkTp3ybbBJLKyLI/KKy3Plb77dr?= =?us-ascii?q?dw90B01A02ztEZ7JVRWeJJG+76RkKk7I+QNRQ+KQHhm+s=3D?= X-remote-hostname: 75-105-60-135.cust.exede.net X-sendergroup: RELAYLIST X-recvListener: Inbound X-SBRS: -10.0 X-Filenames: Received: from 75-105-60-135.cust.exede.net (HELO borage.ViaSatDomain) ([75.105.60.135]) by athena.vistabroadband.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jun 2019 18:34:44 -0700 From: dmarcietf@tomki.com To: dmarc@ietf.org Cc: seth@sethblank.com Message-ID: <0a8b5459-8a9a-7a5b-d169-4c183c43afdd@tomki.com> Date: Fri, 14 Jun 2019 18:34:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 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] nit - data integrity 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, 15 Jun 2019 01:41:23 -0000 A while back there was a request for reports on nits pertaining to the specification. Here is one which I've circulated briefly to some folks recently in person, but I'm not sure how well received it will be here, as a plausible inclusion in the spec. The suggestion: provide guidelines on data integrity, which data providers should follow. Examples: - raw SPF 'fail' should never result in DMARC-SPF 'pass' - raw SPF 'pass' out of alignment with header_from should never result in DMARC-SPF 'pass' - raw DKIM not being shown should never result in DMARC-DKIM 'pass' etc I'm not saying that these situations don't occur for legitimate reasons, but the DMARC result is a logical evaluation. If the result of that evaluation is other than the receiving system wants to apply, then all of the correct evaluations should still be listed, but the disposition can change, and local_policy explain. Is this something which can be simply stated in the specification, or would it belong solely in a 'DMARC XML generator BCP' document? --Tomki From nobody Fri Jun 14 19:23:40 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238AD120100 for ; Fri, 14 Jun 2019 19:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=iGmb3hZZ; dkim=pass (1536-bit key) header.d=taugh.com header.b=INg/uWIb 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 LzTi6KFWC8iC for ; Fri, 14 Jun 2019 19:23:37 -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 3AC441200E5 for ; Fri, 14 Jun 2019 19:23:37 -0700 (PDT) Received: (qmail 88282 invoked from network); 15 Jun 2019 02:23:34 -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=158d5.5d0456a6.k1906; i=johnl-iecc.com@submit.iecc.com; bh=pDCjV/LUmQT8G1HrLxMetFEfY6R2g7+nGIOwtE6fbCI=; b=iGmb3hZZTYDyqmy/9ELEn5xNQ6zzh+KtpW0+Rc8UkBVYwr3Ld/OpOFO5l0K26/4R9wVEm8UbkyXuwyrP5NKBve6IL4MzfT/g9X/kGMOwzFBjQKuSR+I2rUuVY1l5d/vkyx3iQZsJURV4ofXk8oPhQ/PJG8oFiI33ZcqVp/Bt9IqEZEclk6R0Mtd5D1JvWtriw/kK6WVTRI4tcpKutjVbThPJZnWmob8HgZVkd/rSt9NrW121cqy9RZ9PxiobyowY 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=158d5.5d0456a6.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=pDCjV/LUmQT8G1HrLxMetFEfY6R2g7+nGIOwtE6fbCI=; b=INg/uWIbGAs5j71qqN2wsTgdO84uvkrc90cKtHtAOr79mfoQaKiWb5gfvFbja3mTUIg8GCZTZZzsnn5KLNLb3v/nIYQGwtEQXumX2LzDJsmdKAMTvs6dzsamoqaDIasX+lw/VY1FanpXNhAJIjRtXzbjUt2Q41KuRtaPCp/e/BJM0w7HSClaT1Nec4qvR6r9UiFVuP9uJ8EGfVEEbivHJvsuyyHRlmd1mgpylExbU3L9InzA5k0f+GFsUEvJoss5 Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 15 Jun 2019 02:23:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 4050F201561609; Fri, 14 Jun 2019 22:23:33 -0400 (EDT) Date: 14 Jun 2019 22:23:33 -0400 Message-Id: <20190615022334.4050F201561609@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dmarcietf@tomki.com In-Reply-To: <0a8b5459-8a9a-7a5b-d169-4c183c43afdd@tomki.com> 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] nit - data integrity 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, 15 Jun 2019 02:23:39 -0000 In article <0a8b5459-8a9a-7a5b-d169-4c183c43afdd@tomki.com> you write: >Examples: >- raw SPF 'fail' should never result in DMARC-SPF 'pass' >- raw SPF 'pass' out of alignment with header_from should never result >in DMARC-SPF 'pass' >- raw DKIM not being shown should never result in DMARC-DKIM 'pass' >etc I'm sorry, but I don't understand this at all. The DMARC spec is quite clear about what SPF and DKIM results are required for DMARC alignment, and this has no connection I can see with the alignment rules. I also don't know what you mean by a "raw DKIM" or what it means to show it or what you mean by "raw SPF" pass or fail. R's, John From nobody Sat Jun 15 03:59:21 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C0E120098 for ; Sat, 15 Jun 2019 03:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 JsUF8DffwpPC for ; Sat, 15 Jun 2019 03:59:17 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B31120019 for ; Sat, 15 Jun 2019 03:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1560596354; bh=1OxInXjuvzcbwNZ7xebomdrU0oEUzLNxwzOUEEzopOY=; l=743; h=To:Cc:References:From:Date:In-Reply-To; b=CMEs1M6Hrl1sh8WYtOjDQ5SJA9GmsIP7ZkywHh5f6jDrpmXld5DTe6CH18osNE1uD +chAlFZIsqN9JGLf9s4Py+nmgA0zy1P+7e3LVbEbzYF2tlPo/CJI3pSYCEZxocWNYs 6U4qHPZDXIO2j/a/QjEWwZL72SEopoKovQCq+1Y5JgO4DcTmWA7TOuTAyICS4 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 15 Jun 2019 12:59:14 +0200 id 00000000005DC03D.000000005D04CF82.000051C8 To: Vladimir Dubrovin Cc: Dotzero , IETF DMARC WG , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <2c6f2b9e-5ada-f4c3-1162-5c3229229466@tana.it> Date: Sat, 15 Jun 2019 12:59:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 15 Jun 2019 10:59:19 -0000 On Fri 14/Jun/2019 18:25:02 +0200 Vladimir Dubrovin wrote: > If you are implementing DMARC for a new domain (let's say example.org), you > usually start with "p=none". With p=none you receive reports for failed DMARC > for different lists, like ietf.org. Before switching to stronger policy > (p=reject), you may want to know which mailing list will still fail DMARC, and > which lists perform From munging and, as a result, do not fail DMARC. For this > purpose, before switching to "p=reject" it's useful to switch to > "p=quarantine;pct=0". After this, you will only see mailing lists without From > munging in DMARC reports. > I still don't get why "p=quarantine;pct=0" is better than "p=reject;pct=0". Best Ale -- From nobody Sat Jun 15 10:17:04 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4E12002F for ; Sat, 15 Jun 2019 10:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=TqL7q5wW; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0XivkPG9 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 dH3zpl_7qYCW for ; Sat, 15 Jun 2019 10:17:01 -0700 (PDT) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id C34E9120092 for ; Sat, 15 Jun 2019 10:17:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3437; t=1560619013; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=1exZ+q//HyF6v7pj6v/XMSnWOfk=; b=TqL7q5wWmATDoUyCpaYF+lE5vfwQd5A6BYA5d/+UBcFfR49bUX+W8OImaSmTq7 VwiIbBCYfax8cJQJ2Manwt5Be8Dy9PjO0EZuz+hwMfkL7YKa8Jc9/KxJrEtSDwtn Y3kQcuEuEIbQIZZv6RK/e1rdVdwFJ2NNIQ/MOR0svmytw= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 15 Jun 2019 13:16:53 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1411449545.25538.3092; Sat, 15 Jun 2019 13:16:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3437; t=1560618476; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=8QwTLvl H9A4JzHdmv4NLFMpDoHJyXUZXxRxEG47X0FI=; b=0XivkPG9Nz2v5MWeQfRjgtS shYJDnT4t2ZzKiIp1HtOieEQWMrvt5rGNgWRYz6IXTXqOwzLEki5v74HSweRQ8Zy xLOmnNY8vdGEW7t4Gtbo44UJNiJ95IW1JySr25wcq7gRkEiWLYTwmFd2ZW3ZDBUK qnHAhQ6BtZbyX6o02AXg= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 15 Jun 2019 13:07:56 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2983331863.9.41408; Sat, 15 Jun 2019 13:07:56 -0400 Message-ID: <5D0526BF.6090704@isdg.net> Date: Sat, 15 Jun 2019 13:11:27 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 15 Jun 2019 17:17:03 -0000 On 6/14/2019 5:58 PM, Дилян Палаузов wrote: > Hello Ken, > > effectively I proposed handling p=reject and p=quarantine the same way. > > .. > > Lets have an example for p=quaranite: > majordomo@domain is an address where commands are sent and the software receiving the > command always sends an answer, even if the command is unclear. An email is sent > to majordomo@domain. The sending domain has published policy Quarantine. This address > has no spam/junk folder attached to it. The options for an email are: > * reject the email during the SMTP dialog > * accept the email and let majordomo send an answer to it > * arrange a human to decide which emails to discard (handle an imaginary Spam folder for the account). Oh I see your concern/point/proposal now. Yes, I highlighted this basic issue in years past in regards to the handling semantics debates. Even with SPF, how -ALL (FAIL) was interpreted and handled was questioned. Some believed a -ALL FAIL policy is more like a quarantine because "no one actually rejects." But overall, this would be an implementation consideration, not a protocol design consideration. The protocol is correct to have a handling semantics describing both ideas - reject and quarantine. All we can do is highlight the existence of backend mail storage designs and legacy MUA protocol(s) that can not handle a quarantine safely. So at best, you can basically highlight the security design concerns and possible requirements to implement a quarantine concept. There is much mail design history and evolution to consider. The concept of quarantine came with the integrated mail design premise that: - The backend offers user folders or separate mail streams for normal in-box mail and quarantine, spam, junk mail separations. While this is common today for ESPs, this was not always the case for all backend designs. It was often proprietary in nature. No standard here unless we assume everyone using an "Microsoft Exchange" (MAPI) concept or IMAP which is not reality. This coincides with the premise, - The broad range of online and offline MUAs all support the multi-folders provided by the backend. This is again not reality and not always the case. I'll give you a perfect example -- POP3. POP3 is a single mail stream pick up protocol standard. So for a backend that provides POP3 service available to its customers and for the user using MUA with POP3 support, the backend POP3 server MUST NOT merge any suspicious, spam, junk or quarantine mail with the user's normal in-box mail pick up stream. While an advanced POP3 backend server can emulate a single stream consolidation of multi-user folders, it would a major security loop hole to expose POP3 users to quarantined mail merged into the user's pop3 mail stream. For this to work securely, this advanced POP3 server must assume the MUAs are advanced enough or users are advanced enough to write MUA scripts that will separate the single pop3 stream into spam, junk and quarantine folders again. All we can do is highlight how "rejects" can be interpreted differently. After much discussion with SPF, while it didn't provide an specific example using POP3, it was generically described under Local Policy Considerations: https://tools.ietf.org/html/rfc7208#appendix-G.2 It should also be highlighted for DMARC-bis, if not already. -- HLS From nobody Sat Jun 15 11:40:00 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8081200A4 for ; Sat, 15 Jun 2019 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=aKskbd6i; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=K/TNazUg 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 E2unCg9GjMSN for ; Sat, 15 Jun 2019 11:39:57 -0700 (PDT) Received: from mail.winserver.com (ntbbs.santronics.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABE8120019 for ; Sat, 15 Jun 2019 11:39:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1573; t=1560623989; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=JpdUnajkc2X7l0EutDTGGqAtvSo=; b=aKskbd6inyuXfUphFjweiH1OL60IhY1rbyOUt2QcfG5QByY5ztO1e2k446ECt4 ui6csYVCCrsvniOBVH2QuAhavRaf0DBjE2xtJfogy7t648+2NBIJvJfp5j4gYz3M 6GqILmwjKvplS5GHz+YUe91A2J8SVFHcxq7dmjZkkdmlc= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 15 Jun 2019 14:39:49 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1416424807.25538.1124; Sat, 15 Jun 2019 14:39:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1573; t=1560623782; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qwyXpab Z64ayQz9B3CmCBgbeqMfF+lYwDSOTdTbXCJI=; b=K/TNazUgb+hM92hU4URnC8Z kma4Vj/vpqo/5SxbuuLPUVi7FfHr3BNHG0NQH/iv4/Pd27LgzhMomXZBKRJHo4Ni tq63IK9rBigSfAnyVmITqtwPQrEwUQ18Tm4qcSLknfeHhBYzswyO1viExDmKziB4 PhaZz+MsQ6WWIOAKD2OY= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 15 Jun 2019 14:36:22 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2988637145.9.235216; Sat, 15 Jun 2019 14:36:21 -0400 Message-ID: <5D053B78.3090603@isdg.net> Date: Sat, 15 Jun 2019 14:39:52 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <0a8b5459-8a9a-7a5b-d169-4c183c43afdd@tomki.com> In-Reply-To: <0a8b5459-8a9a-7a5b-d169-4c183c43afdd@tomki.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] nit - data integrity 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, 15 Jun 2019 18:40:00 -0000 On 6/14/2019 9:34 PM, dmarcietf=40tomki.com@dmarc.ietf.org wrote: > The suggestion: provide guidelines on data integrity, which data > providers should follow. > Examples: > - raw SPF 'fail' should never result in DMARC-SPF 'pass' > - raw SPF 'pass' out of alignment with header_from should never result > in DMARC-SPF 'pass' > - raw DKIM not being shown should never result in DMARC-DKIM 'pass' > etc > > I'm not saying that these situations don't occur for legitimate > reasons, but the DMARC result is a logical evaluation. If the result > of that evaluation is other than the receiving system wants to apply, > then all of the correct evaluations should still be listed, but the > disposition can change, and local_policy explain. > > Is this something which can be simply stated in the specification, or > would it belong solely in a 'DMARC XML generator BCP' document? Reasons for sending reports? What I think you are saying is: If a domain's DMARC restrictive policy is going be overridden by local DMARC policy, then a DMARC report should be sent to the DMARC domain providing the DMARC technical reasons why DMARC failures were not rejected but instead accepted and passed to the user's eyeballs or quarantined? I think I would interesting to know which DMARC receivers are accepting what are otherwise DMARC rejectable failures. A lawyer might be interested too, in the off chance an innocent user was damaged by the receiver's local DMARC policy. The DMARC domain did its part. The DMARC receiver did not. -- HLS From nobody Sat Jun 15 13:26:00 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35B71200DB for ; Sat, 15 Jun 2019 13:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr0ETirle6QK for ; Sat, 15 Jun 2019 13:25:56 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5064120099 for ; Sat, 15 Jun 2019 13:25:54 -0700 (PDT) Authentication-Results: mail.aegee.org/x5FKPow4016037; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1560630352; i=dkim+MSA-tls@aegee.org; r=y; bh=qasxN+cve75UKqupYGlts8DfLWfAtdIJsRZz6MHgWw0=; h=Subject:From:To:Date:In-Reply-To:References; b=mErk5pTO+T7H5Tyam1votX/kGEQ+nSg1TpQLkho+AMOPF2sMo7hxLn4cj+3bRjMmY D3namQepuQdSKus9wEccseXwnslT3UEQWJ299cHzXZ/y3RAGa85Vhtcc3ybgKBU0NQ r7SKKwq1ZJD8UzJRn3iAfs0CXGWDk7fSuPTPz9i5eLS6ywdwbfDGJw7Z9whq7REYd/ 8zafzr5/C8Kf4yZw8ufRDnOuTsYX/+0pijjMmDYWfMqW6fL0Wn942sLsAuTUyY4yG8 5aCtD4UVo9Clj/8Jv9fA/w5xIn6ba5lEyFMjq42v6CPFBUmj9I9ngyc5rLavHKd1Mb pq3btQXL3f2ecViItGhgsRvZFZ8JnXcSJG6/7lDOggxX2aNZzd5d+RevYx9GD0WrE4 oiKZJT3y7579tHqTUmHqRtXj3LadvCYK1R1B3L9UcqPl7ZHeFbtAdGBuKG6cnISgqJ kGCRfvOlNnqBS7RG7xNNqkZgnghMpBd+NaroQ7NSxkPPZ9MUzORFtmL2jGVZC/2giX aga89cNl6C0gR/K9K6154C11PF+ZszxvV1GpTees20AuEUWb8zKceeNpwqVX79ifZX n1gR25CSi/Fwpdfl44Bwvf2zuX0VHRQSiUsiFhEOiryubPX0mO8UJz3oVFgGtdrwbT TiSyA8xw7/EFTxvC7j3OWAqk= Authentication-Results: mail.aegee.org/x5FKPow4016037; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5FKPow4016037 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 15 Jun 2019 20:25:51 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: hsantos@isdg.net, dmarc@ietf.org Date: Sat, 15 Jun 2019 20:25:50 +0000 In-Reply-To: <5D0526BF.6090704@isdg.net> References: <5D0526BF.6090704@isdg.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 15 Jun 2019 20:25:59 -0000 Hello, p=reject; pct=0 is equivalent to p=quarantine; pct=0. The rest of this email is about (against) handling p=reject and p=quarantine differently. Namely, where a server rejects on p=reject and “quarantines” on p=quarantine. There are more examples, all under the category p=quarantine, where the spam filter does not think a message is spam and DMARC fails (e.g. missing DKIM-Signature): — an autoresponder. The incoming email will be delivered as non-spam, as the spam filter does not classify the email as spam. Would you suppress the autorespond (out-of-office/vacation) message, or will you take the risk to send bad backscatters, risking lowering your IP reputation. Is it up to the domain owner of the original message decide on you sending backscatters, by publishing slightly different dmarc policies? If you handle quarantine as reject there is no such risk of getting bad IP reputation (under these concrete conditions). If no auto-responder is sent and the mail is not classified as spam, the user will rely on the fact, that an autoresponder was sent… big fuzz. — an 1:1 alias to a different server. If your server thinks the email is not spam, but the server to which the alias is redirected thinks the message is spam, or if the user marks it as spam, your IP reputation gets worse. If you handle quarantine as reject there is no such risk. — a MLM (1:many alias), where anybody can send messages - same problem as above, just bigger damage. p=reject and p=quarantine both communicate, that all messages from a domain must have aligned, valid dkim signature or aligned, valid spf result and that for messages from the domain failing DMARC, there must be some penalty. How many distinct penalty levels does a sending domain owner need? One, or more than one? Are two penalty levels enough? Is there justification for two penalty levels? Can the same justification be used to introduce a third penalty level? What does the domain owner/sending domain want do communicate, by using the first, second, or third penalty level? Currently the decisions on handling quarantine/reject in different ways are taken by: * domain owners, who own a domain * spammers, who use the domain of the domain owner, and let's say are distinct from the domain owners * mailbox operators Not taken into account are the users. Why shall a user want to have more messages in its spam folder (assuming that the quarantined message was at the end classified as spam and the email operator handles Reject and Quarantine differently) versus handling p=quarantine as p=reject and having less Spam to pay attention for? About the costs, Quarantine meaning neither deliver, not reject, but something different, can be implemented in this way: the operator does not deliver the emails failing DMARC for a domain with p=querantine to the users, but arranges staff, to decide what to do. The costs for that staff, are the extra costs for having distinct handling of Reject/Quarantine. If there is no such staff, and the decisions are taken by the users, then the costs are the same, these just are shifted to the users. Finally, while DMARC can be used to communicate that all emails from a domain must PASS DMARC rules, why there is a need to communicate what to do with emails that fail DMARC from: the domain? The DMARC specification can be simplified, by leaving the hanlding of such emails ultimately up to the receiving host and then there is no need to iterate the options at protocol level for the sending domain. (The option, that all emails from a domain must have aligned DKIM signatures, but it is up to the recipient what to do with messages without valid dkim-signature or spf result is anyway missing)j Regards Дилян On Sat, 2019-06-15 at 13:11 -0400, Hector Santos wrote: > On 6/14/2019 5:58 PM, Дилян Палаузов wrote: > > Hello Ken, > > > > effectively I proposed handling p=reject and p=quarantine the same way. > > > > .. > > > > Lets have an example for p=quaranite: > > majordomo@domain is an address where commands are sent and the software receiving the > > command always sends an answer, even if the command is unclear. An email is sent > > to majordomo@domain. The sending domain has published policy Quarantine. This address > > has no spam/junk folder attached to it. The options for an email are: > > * reject the email during the SMTP dialog > > * accept the email and let majordomo send an answer to it > > * arrange a human to decide which emails to discard (handle an imaginary Spam folder for the account). > > Oh I see your concern/point/proposal now. > > Yes, I highlighted this basic issue in years past in regards to the > handling semantics debates. Even with SPF, how -ALL (FAIL) was > interpreted and handled was questioned. Some believed a -ALL FAIL > policy is more like a quarantine because "no one actually rejects." > > But overall, this would be an implementation consideration, not a > protocol design consideration. The protocol is correct to have a > handling semantics describing both ideas - reject and quarantine. > > All we can do is highlight the existence of backend mail storage > designs and legacy MUA protocol(s) that can not handle a quarantine > safely. So at best, you can basically highlight the security design > concerns and possible requirements to implement a quarantine concept. > > There is much mail design history and evolution to consider. The > concept of quarantine came with the integrated mail design premise that: > > - The backend offers user folders or separate mail streams for normal > in-box mail and quarantine, spam, junk mail separations. While this is > common today for ESPs, this was not always the case for all backend > designs. It was often proprietary in nature. No standard here unless > we assume everyone using an "Microsoft Exchange" (MAPI) concept or > IMAP which is not reality. This coincides with the premise, > > - The broad range of online and offline MUAs all support the > multi-folders provided by the backend. This is again not reality and > not always the case. > > I'll give you a perfect example -- POP3. > > POP3 is a single mail stream pick up protocol standard. So for a > backend that provides POP3 service available to its customers and for > the user using MUA with POP3 support, the backend POP3 server MUST NOT > merge any suspicious, spam, junk or quarantine mail with the user's > normal in-box mail pick up stream. > > While an advanced POP3 backend server can emulate a single stream > consolidation of multi-user folders, it would a major security loop > hole to expose POP3 users to quarantined mail merged into the user's > pop3 mail stream. For this to work securely, this advanced POP3 > server must assume the MUAs are advanced enough or users are advanced > enough to write MUA scripts that will separate the single pop3 stream > into spam, junk and quarantine folders again. > > All we can do is highlight how "rejects" can be interpreted > differently. After much discussion with SPF, while it didn't provide > an specific example using POP3, it was generically described under > Local Policy Considerations: > > https://tools.ietf.org/html/rfc7208#appendix-G.2 > > It should also be highlighted for DMARC-bis, if not already. > From nobody Sat Jun 15 15:13:22 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633A412012A for ; Sat, 15 Jun 2019 15:13:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.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 M0o4M4rOxN5g for ; Sat, 15 Jun 2019 15:13:18 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id CEE311200C5 for ; Sat, 15 Jun 2019 15:13:17 -0700 (PDT) Received: from [192.168.0.88] (unknown [37.228.251.105]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 1AFD19F146 for ; Sat, 15 Jun 2019 15:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1560636796; bh=BnzR9+fhthKL7bpIReS48G92oRIqnOuc4/DdLlGg3Hg=; h=From:Subject:Date:References:To:In-Reply-To:From; b=K/627I+nIHv0Y1vz+qOs9FBc/AYBE7pi7CkaIYaFrnWmSfBKadKteBzDJisHpaiTe PUU2e7hmyl9VzWCoWjmsTkwMRFCiV4fEMzNbQs8oEGi+BjroRzen06PC1CoMvvRrVB V3JnHM0mXZdh2Y6JFK63f61PR3Foq/rR4lCCpzas= From: Steve Atkins Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 15 Jun 2019 23:13:13 +0100 References: <5D0526BF.6090704@isdg.net> To: dmarc In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 15 Jun 2019 22:13:21 -0000 > On Jun 15, 2019, at 9:25 PM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD = =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 = wrote: >=20 > Hello, >=20 > p=3Dreject; pct=3D0 is equivalent to p=3Dquarantine; pct=3D0. I've not been following this thread too closely so I might be missing = something, but under current DMARC spec I don't think that's so - see section 6.6.4. If I've missed the point ... never mind, carry on. Cheers, Steve >=20 > The rest of this email is about (against) handling p=3Dreject and = p=3Dquarantine differently. Namely, where a server > rejects on p=3Dreject and =E2=80=9Cquarantines=E2=80=9D on = p=3Dquarantine. >=20 > There are more examples, all under the category p=3Dquarantine, where = the spam filter does not think a message is spam and > DMARC fails (e.g. missing DKIM-Signature): >=20 > =E2=80=94 an autoresponder. The incoming email will be delivered as = non-spam, as the spam filter does not classify the email as > spam. Would you suppress the autorespond (out-of-office/vacation) = message, or will you take the risk to send bad > backscatters, risking lowering your IP reputation. Is it up to the = domain owner of the original message decide on you > sending backscatters, by publishing slightly different dmarc policies? = If you handle quarantine as reject there is no > such risk of getting bad IP reputation (under these concrete = conditions). If no auto-responder is sent and the mail is > not classified as spam, the user will rely on the fact, that an = autoresponder was sent=E2=80=A6 big fuzz. >=20 > =E2=80=94 an 1:1 alias to a different server. If your server thinks = the email is not spam, but the server to which the alias is > redirected thinks the message is spam, or if the user marks it as = spam, your IP reputation gets worse. If you handle > quarantine as reject there is no such risk. >=20 > =E2=80=94 a MLM (1:many alias), where anybody can send messages - same = problem as above, just bigger damage. >=20 > p=3Dreject and p=3Dquarantine both communicate, that all messages from = a domain must have aligned, valid dkim signature or > aligned, valid spf result and that for messages from the domain = failing DMARC, there must be some penalty. >=20 > How many distinct penalty levels does a sending domain owner need? >=20 > One, or more than one? Are two penalty levels enough? Is there = justification for two penalty levels? Can the same=20 > justification be used to introduce a third penalty level? What does = the domain owner/sending domain want do > communicate, by using the first, second, or third penalty level? >=20 > Currently the decisions on handling quarantine/reject in different = ways are taken by: > * domain owners, who own a domain > * spammers, who use the domain of the domain owner, and let's say are = distinct from the domain owners > * mailbox operators >=20 > Not taken into account are the users. Why shall a user want to have = more messages in its spam folder (assuming that the > quarantined message was at the end classified as spam and the email = operator handles Reject and Quarantine differently) > versus handling p=3Dquarantine as p=3Dreject and having less Spam to = pay attention for? >=20 > About the costs, Quarantine meaning neither deliver, not reject, but = something different, can be implemented in this > way: the operator does not deliver the emails failing DMARC for a = domain with p=3Dquerantine to the users, but arranges > staff, to decide what to do. The costs for that staff, are the extra = costs for having distinct handling of > Reject/Quarantine. If there is no such staff, and the decisions are = taken by the users, then the costs are the same, > these just are shifted to the users. >=20 > Finally, while DMARC can be used to communicate that all emails from a = domain must PASS DMARC rules, why there is a need > to communicate what to do with emails that fail DMARC from: the = domain? The DMARC specification can be simplified, by > leaving the hanlding of such emails ultimately up to the receiving = host and then there is no need to iterate the options > at protocol level for the sending domain. (The option, that all emails = from a domain must have aligned DKIM signatures, > but it is up to the recipient what to do with messages without valid = dkim-signature or spf result is anyway missing)j >=20 > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD >=20 > On Sat, 2019-06-15 at 13:11 -0400, Hector Santos wrote: >> On 6/14/2019 5:58 PM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB= =D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: >>> Hello Ken, >>>=20 >>> effectively I proposed handling p=3Dreject and p=3Dquarantine the = same way. >>>=20 >>> .. >>>=20 >>> Lets have an example for p=3Dquaranite: >>> majordomo@domain is an address where commands are sent and the = software receiving the >>> command always sends an answer, even if the command is unclear. An = email is sent >>> to majordomo@domain. The sending domain has published policy = Quarantine. This address >>> has no spam/junk folder attached to it. The options for an email = are: >>> * reject the email during the SMTP dialog >>> * accept the email and let majordomo send an answer to it >>> * arrange a human to decide which emails to discard (handle an = imaginary Spam folder for the account). >>=20 >> Oh I see your concern/point/proposal now. >>=20 >> Yes, I highlighted this basic issue in years past in regards to the=20= >> handling semantics debates. Even with SPF, how -ALL (FAIL) was=20 >> interpreted and handled was questioned. Some believed a -ALL FAIL=20 >> policy is more like a quarantine because "no one actually rejects." >>=20 >> But overall, this would be an implementation consideration, not a=20 >> protocol design consideration. The protocol is correct to have a=20 >> handling semantics describing both ideas - reject and quarantine. >>=20 >> All we can do is highlight the existence of backend mail storage=20 >> designs and legacy MUA protocol(s) that can not handle a quarantine=20= >> safely. So at best, you can basically highlight the security design=20= >> concerns and possible requirements to implement a quarantine concept. >>=20 >> There is much mail design history and evolution to consider. The=20 >> concept of quarantine came with the integrated mail design premise = that: >>=20 >> - The backend offers user folders or separate mail streams for normal=20= >> in-box mail and quarantine, spam, junk mail separations. While this = is=20 >> common today for ESPs, this was not always the case for all backend=20= >> designs. It was often proprietary in nature. No standard here = unless=20 >> we assume everyone using an "Microsoft Exchange" (MAPI) concept or=20 >> IMAP which is not reality. This coincides with the premise, >>=20 >> - The broad range of online and offline MUAs all support the=20 >> multi-folders provided by the backend. This is again not reality and=20= >> not always the case. >>=20 >> I'll give you a perfect example -- POP3. >>=20 >> POP3 is a single mail stream pick up protocol standard. So for a=20 >> backend that provides POP3 service available to its customers and for=20= >> the user using MUA with POP3 support, the backend POP3 server MUST = NOT=20 >> merge any suspicious, spam, junk or quarantine mail with the user's=20= >> normal in-box mail pick up stream. >>=20 >> While an advanced POP3 backend server can emulate a single stream=20 >> consolidation of multi-user folders, it would a major security loop=20= >> hole to expose POP3 users to quarantined mail merged into the user's=20= >> pop3 mail stream. For this to work securely, this advanced POP3=20 >> server must assume the MUAs are advanced enough or users are advanced=20= >> enough to write MUA scripts that will separate the single pop3 stream=20= >> into spam, junk and quarantine folders again. >>=20 >> All we can do is highlight how "rejects" can be interpreted=20 >> differently. After much discussion with SPF, while it didn't provide=20= >> an specific example using POP3, it was generically described under=20 >> Local Policy Considerations: >>=20 >> https://tools.ietf.org/html/rfc7208#appendix-G.2 >>=20 >> It should also be highlighted for DMARC-bis, if not already. >>=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Jun 16 08:43:04 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11651201A0 for ; Sun, 16 Jun 2019 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_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=isdg.net header.b=BGSW+aln; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=gJGgOAyI 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 IQLOYg7C5RP8 for ; Sun, 16 Jun 2019 08:43:00 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 814F01201D0 for ; Sun, 16 Jun 2019 08:43:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1754; t=1560699771; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=8oiiyCXHjt5iUb5LqX4yKc5/iDE=; b=BGSW+alno5SJpt57WJeFWsMgV+i7yLZZIFeQuXJXFsK2kvQrUQvZwEE6OZxP+c EbAc3KWxpSJ1/p4zINRjW1xn/bjaZBSiwog5PtQwyrLW6lYkYeOn2ihv4nIZTC3d MUbzUmdSX8KVIuv3nzGtLQREDp1nDM8PVKZD+SzUxXpJM= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sun, 16 Jun 2019 11:42:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1492206286.25538.5304; Sun, 16 Jun 2019 11:42:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1754; t=1560699564; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OahdNWu aJz1VH5RPhE44in5vxMUNj04iPdCh9bzsoYE=; b=gJGgOAyIq8bJWb9d6pEWcjM jP1mt0Dnd/eESnXZf/q3KJSjandMhQ+KxwGdIQAoJwH2YMCacrxiJJ2Ye9sASTqU LYNtopOA9Ha11r+cxhHYdjwNw6llQ2XzO31cfsKdDif94E4+jgc5iicCxc0FuJRL Rf+uT87dZn7+bw87i168= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sun, 16 Jun 2019 11:39:24 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 3064419410.9.165952; Sun, 16 Jun 2019 11:39:23 -0400 Message-ID: <5D06636E.7040608@isdg.net> Date: Sun, 16 Jun 2019 11:42:38 -0400 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5D0526BF.6090704@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 16 Jun 2019 15:43:03 -0000 On 6/15/2019 6:13 PM, Steve Atkins wrote: > > >> On Jun 15, 2019, at 9:25 PM, wrote: >> >> Hello, >> >> p=reject; pct=0 is equivalent to p=quarantine; pct=0. > > I've not been following this thread too closely so I might > be missing something, but under current DMARC spec I don't > think that's so - see section 6.6.4. > > If I've missed the point ... never mind, carry on. If I follow myself, I think it could be expressed as: p=reject; pct=0; is effectively equivalent to p=quarantine; pct=100; Given the order of mail "restriction" or "filtering" from high to low of reaching the user's eyeballs: p=reject never accepted or accepted/discarded p=quarantine accepted, imported into spam box, outside inbox p=none accepted, imported into inbox The "pct" effectively forces a fallback to the next lower applicable policy once the pct of failed mail has been processed: p=reject; pct=X; fallback to p=quarantine p=quarantine; pct=X; fallback to p=none p=none; pct=X fallback to UNDEFINED, N/A where X can be 0 to 100. When pct=100, which is the default, then the fallback would not apply since the explicit domain policy is applied to all DMARC failed messages. The receiver rejects mail with p=reject and quarantines mail with p=quarantine. If there is an explicit pct=0, then effectively, the fallback is to be applied immediately, thus: p=reject; pct=0; is effectively equivalent to p=quarantine; pct=100; and p=quarantine; pct=0; is effectively equivalent to p=none; pct=100; Because of the fallback and quarantine implementation complexity and how failed messages can reach users, the OP is proposing to abolish the quarantine policy. -- HLS From nobody Fri Jun 21 11:15:02 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446261200B8 for ; Fri, 21 Jun 2019 11:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tomki.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eANEPb2Xk4KR for ; Fri, 21 Jun 2019 11:14:59 -0700 (PDT) Received: from athena.vistabroadband.net (athena.vistabroadband.net [69.39.252.35]) (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 1377412001A for ; Fri, 21 Jun 2019 11:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomki.com; l=650; q=dns/txt; s=tomki; t=1561140899; x=1561313699; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; z=To:=20dmarc@ietf.org|Cc:=20seth@sethblank.com,=20zwicky@ oath.com|From:=20Tomki=20|Subject:=20spec =20nit=20-=20which=20DKIM=20to=20report|Message-ID:=20<7c d366d2-ab8d-cce8-67ff-59b79183cd67@tomki.com>|Date:=20Fri ,=2021=20Jun=202019=2011:15:03=20-0700|MIME-Version:=201. 0|Content-Transfer-Encoding:=207bit; bh=5jsmqvUa+oXCfxwCUY+/0jXAe1lOaZV2xZpMXdWfVFA=; b=OdaT+tthnSH2HIlPNarpGdhNR4lThW6FwyXVskqyLaDMz+UUe6hxyq8m M6AUWMc372h5cLRn97H3r41vNVkRx9i6K/vKAnGzTkp70DHGb0gwgi/jN 2WqpXJZyDT7VxBh2TH6nON3l/K9c/gyZSbhNLirz9OUpjTvbrP5Lb0OGK ZuP5THRPni3u12HhoytBKiW6/ZYrN8ACNEklvXzHZHS0DGCbAquSMc+aA +3KDmwIWf4q5+Y6v30WYGKW2mxPDLAm1YI4oazs+Mu6ylaaIChS72KFEv 5YDuW6d6Ik+JRQtFQRTEIcfbr16iDCdjFRA/KWSxqujDDKugJGEl2Px8Z Q==; IronPort-SDR: anW/CsyQq7aNQqN7pCaBpAOZu4Ua97yV7DumUQy+CbhL+IT2EzanpVtJkZLiQykl/IoMPxy/bR lFpU01l2CXT9GhdTC9e+FszQCWbPsghB4ZYojI2ZuxNXtTMo63HjfNQJ9oI0EZEKDNtg7qKG1Y 8+gxxxFYja5+4E1qZ7eESkiyhaKWWyVuhLW1V3tX0dlaHfvv8VGxNpq6UJK6D2cwXTRSkw33W6 w9vatFJYCPWYFyuHle4QwMoGKPFb2//OGhsEZ8KvMQnEwgLAzVmxZ6JbXIsZd5TsIlISL9+rUO ng8= X-Filenames: X-SBRS: -10.0 X-recvListener: Inbound X-sendergroup: RELAYLIST X-remote-hostname: 75-105-60-135.cust.exede.net X-IronPort-AV: E=Sophos;i="5.63,401,1557212400"; d="scan'208";a="45034432" Received: from 75-105-60-135.cust.exede.net (HELO borage.ViaSatDomain) ([75.105.60.135]) by athena.vistabroadband.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2019 11:14:53 -0700 To: dmarc@ietf.org Cc: seth@sethblank.com, zwicky@oath.com From: Tomki Message-ID: <7cd366d2-ab8d-cce8-67ff-59b79183cd67@tomki.com> Date: Fri, 21 Jun 2019 11:15:03 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 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] spec nit - which DKIM to report 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, 21 Jun 2019 18:15:00 -0000 As mentioned by Elizabeth recently: (Elizabeth please chime in if this doesn't capture your meaning) the spec does not define *which* DKIM signature should be reported in the DMARC RUA created by a receiver. The proposed resolution to this is that if the receiver does not provide the complete set of DKIM signatures found, they should provide (in order of preference) 1. a signature which passed DKIM in strict alignment with the From: header domain 2. a signature which passed DKIM in relaxed alignment with the From: header domain 3. some other signature that passed DKIM 4. some other signature that didn't pass DKIM --Tomki From nobody Fri Jun 21 11:46:43 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A442112012C for ; Fri, 21 Jun 2019 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 (1536-bit key) header.d=iecc.com header.b=IxWTyAXN; dkim=pass (1536-bit key) header.d=taugh.com header.b=nwdzY7ig 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 spOcj1HAqqmq for ; Fri, 21 Jun 2019 11:46:40 -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 7E88C120384 for ; Fri, 21 Jun 2019 11:46:30 -0700 (PDT) Received: (qmail 17163 invoked from network); 21 Jun 2019 18:46:27 -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=4309.5d0d2603.k1906; i=johnl-iecc.com@submit.iecc.com; bh=Xlac4Mb+MVwJ3di/cuhVp+tA6eJLcahoV4xzwwG4smc=; b=IxWTyAXNpFJLJZN1JD0Vx3U8AjtpUncpj85mGHnYK/GQmwqGFw+bXV6iX9u5ue95bDMiKt8CdQaXaXgSu2m5mODI+akIyJDPdmfTZULALIr1kjEsMVjovHdu6NGdYzehMTfuGUJ2QTFjMfRqI/hubKAGfJXYfq74KUuJ3JyBHgNs9dOBW4bUWI1UJho3dlrFZGPobdoP1DhkMohB1h7wtL1Mjr0L1wfpg81hoNLJ5N+nxhDYaext4yPaiSgZcsom 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=4309.5d0d2603.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=Xlac4Mb+MVwJ3di/cuhVp+tA6eJLcahoV4xzwwG4smc=; b=nwdzY7ig05h+Z+iiKTZHqGukC2uVyb2VjJESLLzP5+O5+IsZmIdozklQs2qcqpiGl1NTe5b0EHFZosjuL04Y+2RRiJW81Jpvw4HUkPla3xnwVNqOahv84dxANUNBDGHEiWoO8E4nuOIWDLcX4w5VsuiaIE1zGZyNKL9WNAi0gecxxRfAllkgM8Pm+jjcsYsGXQNM0htc22N3NtHRyHD+Pzzb4dWsnS21pQmgzB6yiEGUVw9tGTb5TpzIdohRviD6 Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 21 Jun 2019 18:46:26 -0000 Received: by ary.qy (Postfix, from userid 501) id AE1B52016298ED; Fri, 21 Jun 2019 14:46:26 -0400 (EDT) Date: 21 Jun 2019 14:46:26 -0400 Message-Id: <20190621184626.AE1B52016298ED@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: tki@tomki.com In-Reply-To: <7cd366d2-ab8d-cce8-67ff-59b79183cd67@tomki.com> 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] spec nit - which DKIM to report 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, 21 Jun 2019 18:46:42 -0000 In article <7cd366d2-ab8d-cce8-67ff-59b79183cd67@tomki.com> you write: >As mentioned by Elizabeth recently: (Elizabeth please chime in if this >doesn't capture your meaning) > >the spec does not define *which* DKIM signature should be reported in >the DMARC RUA created by a receiver. The proposed resolution to this is >that if the receiver does not provide the complete set of DKIM >signatures found, they should provide (in order of preference) >1. a signature which passed DKIM in strict alignment with the From: >header domain >2. a signature which passed DKIM in relaxed alignment with the From: >header domain >3. some other signature that passed DKIM >4. some other signature that didn't pass DKIM This seeems overcomplex. How about saying the reports SHOULD include all valid DKIM reports. If they can't, they can't, and I don't see any benefit in offering advice on how not to comply. From nobody Fri Jun 21 12:06:53 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8ADF120472 for ; Fri, 21 Jun 2019 12:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=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=otoh.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViuKtGDf_xzR for ; Fri, 21 Jun 2019 12:06:48 -0700 (PDT) Received: from suricate.otoh.org (suricate.otoh.org [173.11.101.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF721120456 for ; Fri, 21 Jun 2019 12:06:37 -0700 (PDT) Received: from [172.132.15.241] (unknown [209.131.62.183]) (Authenticated sender: zwicky) by suricate.otoh.org (Postfix) with ESMTPSA id C4D3C11988; Fri, 21 Jun 2019 19:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1561143990; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NE/UgPErBEYp9DNkHcmnbXKYsH1TFvTmyF8G4BUgqus=; b=aufVSV9HKkQQkf5xd+wmS7WlpNPMdqEXYVneAmUl2atZYeHNqiiRK15Hl1rGziCZbvwe2n PYvXRdLVhziWxSR4Y6YyCBjTl17BPZsRVg8AWtj6jfsoGDVT9ojoSIA+OU2uqwtuSiNsiH IxbaSmnMk0zmibWCA8H/BS4+TvUID5I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Elizabeth Zwicky X-Mailer: iPhone Mail (16F203) In-Reply-To: <20190621184626.AE1B52016298ED@ary.qy> Date: Fri, 21 Jun 2019 12:06:13 -0700 Cc: dmarc@ietf.org, tki@tomki.com Content-Transfer-Encoding: quoted-printable Message-Id: <8C941177-5B45-4B69-A2CB-C774BFB543FD@otoh.org> References: <20190621184626.AE1B52016298ED@ary.qy> To: John Levine ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1561143992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NE/UgPErBEYp9DNkHcmnbXKYsH1TFvTmyF8G4BUgqus=; b=d8RsHhrvFx9Fzn+bTCkbWjPa7fwlAxjGUHr1wE7RxNfyb0w4Tc/0tozl/CPITovfAvItQ9 T9S5mDruUCGewaSYh/O6mVULkjbDpcXe6LHvO7pIUQ8Nhly/z/yWxbJzMg81GjjtLepHau +ldPq6OyunpV2Hn0rOWPRkioJwWiDN4= ARC-Seal: i=1; s=2014-12-30; d=otoh.org; t=1561143992; a=rsa-sha256; cv=none; b=uOIIFF+1NsXflwPQLyYFEDCt3tbwxgqYtKJJa1Tra9gp0bDcFJ+p/mtkhsg7Mg5uvJt8rS r27jpA3XgtwkVcYG0HnDzxAqeMTQd0ZtgeagT6KHxaIXDhUQ82IW+XKCneSNsiul8r+Zrb hjs5Rett0E3WpRVFTW9wTyT5AhP1r1w= ARC-Authentication-Results: i=1; suricate.otoh.org; auth=pass smtp.auth=zwicky smtp.mailfrom=zwicky@otoh.org Archived-At: Subject: Re: [dmarc-ietf] spec nit - which DKIM to report 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, 21 Jun 2019 19:06:52 -0000 I believe they MUST contain any aligned DKIM signature regardless of validit= y and SHOULD contain an entry for each domain, selector, result triple.=20 Elizabeth=20 > On Jun 21, 2019, at 11:46 AM, John Levine wrote: >=20 > In article <7cd366d2-ab8d-cce8-67ff-59b79183cd67@tomki.com> you write: >> As mentioned by Elizabeth recently: (Elizabeth please chime in if this=20= >> doesn't capture your meaning) >>=20 >> the spec does not define *which* DKIM signature should be reported in=20 >> the DMARC RUA created by a receiver. The proposed resolution to this is=20= >> that if the receiver does not provide the complete set of DKIM=20 >> signatures found, they should provide (in order of preference) >> 1. a signature which passed DKIM in strict alignment with the From:=20 >> header domain >> 2. a signature which passed DKIM in relaxed alignment with the From:=20 >> header domain >> 3. some other signature that passed DKIM >> 4. some other signature that didn't pass DKIM >=20 > This seeems overcomplex. How about saying the reports SHOULD include > all valid DKIM reports. If they can't, they can't, and I don't see > any benefit in offering advice on how not to comply. >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Jun 21 12:11:53 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33E212036D for ; Fri, 21 Jun 2019 12:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=lWMQ8+kP; dkim=pass (1536-bit key) header.d=taugh.com header.b=A8f83fT5 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 KgqGwO-qwiHV for ; Fri, 21 Jun 2019 12:11:50 -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 6CE1D1203B5 for ; Fri, 21 Jun 2019 12:11:46 -0700 (PDT) Received: (qmail 22232 invoked from network); 21 Jun 2019 19:11:44 -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=56d6.5d0d2bf0.k1906; i=johnl-iecc.com@submit.iecc.com; bh=rctmPncb86FiKbd8XnAiCKuCVjtMM/D0g+NBYmWWXF8=; b=lWMQ8+kP0litN6mmZYDFjbRvrNcwN3qtXYinHj7bsrzBXpZyFeaXdGcJNcaIBv280jabXXpGt3MT0fq6GhyuJKCi4JfD8GuEQbMVhkUulvU0hgQ7ZfbediRbaIgEL51OGvaXQdg4/xDCUbICzJbe3phcnv4/loDj1gLlTT9c2ribZMaGKnUI/s8yaW+g31rFT/wQHT/InhTREulcFAkKrlgsHcDPIZ7SXSIh5eRWxJK21cXW3UDOtOo7rDfA02k8 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=56d6.5d0d2bf0.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=rctmPncb86FiKbd8XnAiCKuCVjtMM/D0g+NBYmWWXF8=; b=A8f83fT5EwfQLug6F/EGSTpHNgPMfTHN6QM/fFx2Hv+Gqr7RVyzsaIwbHhx9hw56rWBhBwWcHoTcJzZYbtyDdhvLGzckEzWI8AhDZnZKc3zvDYdfrf3IcJ1p1aUWWyey7Dsig0JGOnWkwzRzfGxxzzJdaAbpuoyq10UzpIJDInYWKNhVVAPb1YqkXduo7BpplWCGKNfazTQUa5VKfwUEk/NFtlaPtTZ3WqDTHMDtD05wPZLJC6PA5CsAjcs7DBrU 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.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 Jun 2019 19:11:44 -0000 Date: 21 Jun 2019 15:11:43 -0400 Message-ID: From: "John R Levine" To: "Elizabeth Zwicky" Cc: dmarc@ietf.org, tki@tomki.com In-Reply-To: <8C941177-5B45-4B69-A2CB-C774BFB543FD@otoh.org> References: <20190621184626.AE1B52016298ED@ary.qy> <8C941177-5B45-4B69-A2CB-C774BFB543FD@otoh.org> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] spec nit - which DKIM to report 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, 21 Jun 2019 19:11:52 -0000 > I believe they MUST contain any aligned DKIM signature regardless of validity and SHOULD contain an entry for each domain, selector, result triple. RFC 7489 says: The report SHOULD include the following data: o The DMARC policy discovered and applied, if any o The selected message disposition o The identifier evaluated by SPF and the SPF result, if any o The identifier evaluated by DKIM and the DKIM result, if any o For both DKIM and SPF, an indication of whether the identifier was in alignment (and a bunch of other stuff) I don't see any basis to change this, since as long as the report's format and syntax are correct, it'll interoperate. It may not have all the hints the report's recipient would like, but life is like that. R's, John From nobody Fri Jun 21 12:15:28 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE681201BE for ; Fri, 21 Jun 2019 12:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=otoh.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjPijtscn_gK for ; Fri, 21 Jun 2019 12:15:25 -0700 (PDT) Received: from suricate.otoh.org (suricate.otoh.org [173.11.101.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78992120096 for ; Fri, 21 Jun 2019 12:15:25 -0700 (PDT) Received: from [172.132.15.241] (unknown [209.131.62.183]) (Authenticated sender: zwicky) by suricate.otoh.org (Postfix) with ESMTPSA id B2DC31198D; Fri, 21 Jun 2019 19:15:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1561144520; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dLjv+YtGuIXNR3L47s2x9LB8102jG0sNfn05vF8unVQ=; b=H/+Jt8pCrB8mEhLZNje/0HYM5hHB8Ws0RMemZJO5a4MoWFUX9HkiZxIEzXlJfpwj0fQ4Pv T417Y4TSGMRFC1whNNgze2AhmdJPAmxX4YXMWI8gciANWR9DD19T0sqrcPA6wMgpWfEMMJ Ou36Rz34jlPb7HY4jlAkyI0cimjImHs= Content-Type: multipart/alternative; boundary=Apple-Mail-E70FB312-3F88-44F3-9D10-6C82755E1AF9 Mime-Version: 1.0 (1.0) From: Elizabeth Zwicky X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Fri, 21 Jun 2019 12:15:19 -0700 Cc: dmarc@ietf.org, tki@tomki.com Content-Transfer-Encoding: 7bit Message-Id: <0C6B5A70-6373-4DC1-9AB3-E0745F4D3364@otoh.org> References: <20190621184626.AE1B52016298ED@ary.qy> <8C941177-5B45-4B69-A2CB-C774BFB543FD@otoh.org> To: John R Levine ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1561144520; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dLjv+YtGuIXNR3L47s2x9LB8102jG0sNfn05vF8unVQ=; b=Rqu3rBv3M1MlXdwXmOwUF0eihbqjur4g/iuGUWtwbeMpiyUu9kD89qMDORWxbmKEDNwDYL tAYp2cj569aDsprv+hnHiPYlxP9NclzdRucM9ULPvIPcdpJ+ssySLc1N35uLxc/Q5c4hQq yVAa9dShsTEyFXqeBKD1sEJbq6v3QeQ= ARC-Seal: i=1; s=2014-12-30; d=otoh.org; t=1561144520; a=rsa-sha256; cv=none; b=qiDSk9RuLtyQ+/tfLEwhvyQNbKbO+6p80RVzLxCJJqtpiM/jI/iYPoNND6zyGNy/q1/WZf iqE9WFappnjpDQiW8BREgEWtRecQEaTb+QEVywAPYK7Qoks/1Vbgye2c9fxNnD9prf2mMG oTAjzVdbADqdAcLa/BRxwYskPHlWxqs= ARC-Authentication-Results: i=1; suricate.otoh.org; auth=pass smtp.auth=zwicky smtp.mailfrom=zwicky@otoh.org Archived-At: Subject: Re: [dmarc-ietf] spec nit - which DKIM to report 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, 21 Jun 2019 19:15:27 -0000 --Apple-Mail-E70FB312-3F88-44F3-9D10-6C82755E1AF9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The problem with that language is that > o The identifier evaluated by DKIM and the DKIM result, if any is genuinely unclear. Often there are multiple identifiers. Does this mean I= can pick any one of them? (That does not actually provide sufficient intero= perability.) If there=E2=80=99s a specific one I should pick, which is it? Elizabeth=20 On Jun 21, 2019, at 12:11 PM, John R Levine wrote: >> I believe they MUST contain any aligned DKIM signature regardless of vali= dity and SHOULD contain an entry for each domain, selector, result triple. >=20 > RFC 7489 says: >=20 > The report SHOULD include the following data: >=20 > o The DMARC policy discovered and applied, if any >=20 > o The selected message disposition >=20 > o The identifier evaluated by SPF and the SPF result, if any >=20 > o The identifier evaluated by DKIM and the DKIM result, if any >=20 > o For both DKIM and SPF, an indication of whether the identifier was > in alignment >=20 > (and a bunch of other stuff) >=20 > I don't see any basis to change this, since as long as the report's format= and syntax are correct, it'll interoperate. It may not have all the hints t= he report's recipient would like, but life is like that. >=20 > R's, > John --Apple-Mail-E70FB312-3F88-44F3-9D10-6C82755E1AF9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The problem with that language is that
=  o  The identifier evaluated by DKIM and the DKIM result,= if any

is genuin= ely unclear. Often there are multiple identifiers. Does this mean I can pick= any one of them? (That does not actually provide sufficient interoperabilit= y.) If there=E2=80=99s a specific one I should pick, which is it?

Elizabeth 
=

On Jun 21, 2019, at 12:11 PM, John R Levine &= lt;johnl@taugh.com> wrote:

=
<= span>I believe they MUST contain any aligned DKIM signature regardless of va= lidity and SHOULD  contain an entry for each domain, selector, result t= riple.

RFC 7489 says:
  The report SHOULD include the followin= g data:

  o  The DMARC poli= cy discovered and applied, if any

 &n= bsp;o  The selected message disposition

  o  The identifier evaluated by SPF and the SPF result, i= f any

  o  The identifier e= valuated by DKIM and the DKIM result, if any

  o  For both DKIM and SPF, an indication of whether the i= dentifier was
     in alignment

(and a bunch of other stuff)
=
I don't see any basis to change this, since as long as the r= eport's format and syntax are correct, it'll interoperate.  It may not h= ave all the hints the report's recipient would like, but life is like that.<= /span>

R's,
John
<= /blockquote>= --Apple-Mail-E70FB312-3F88-44F3-9D10-6C82755E1AF9-- From nobody Fri Jun 21 12:24:13 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AB0120130 for ; Fri, 21 Jun 2019 12:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1536-bit key) header.d=iecc.com header.b=IFUxiDKj; dkim=pass (1536-bit key) header.d=taugh.com header.b=R6ZT1a9k 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 8ra5OgcOuj_i for ; Fri, 21 Jun 2019 12:24:09 -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 83112120096 for ; Fri, 21 Jun 2019 12:24:09 -0700 (PDT) Received: (qmail 25432 invoked from network); 21 Jun 2019 19:24:07 -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=6356.5d0d2ed7.k1906; i=johnl-iecc.com@submit.iecc.com; bh=3MVSYjdcf7HbxwaOvclgeGwI+is5VbRZigtSsm/jiUU=; b=IFUxiDKjMOPuvd6jIpB5u2trOlI9cBvc2jFfD9ZZXvgCBkeMVL1MkNJUJ8B6FOHn+uah6Bi43W9SaV1xugmanFwLT+JswnwNWZbVi4weCEYsRtYD38gWB8gReAWDCgYFVu0VeHRRULqLPpWiFIumAm1tiD/0UksE0+6s2Ls2M7HCMWC9/xSOYtvYz3dEh/CIKiyGm/iqwOOD7xLe2g2RZAmILeHwTR6JYvdIUrk8KS4SCn/C/t94YJ0eu2FHsxjd 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=6356.5d0d2ed7.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=3MVSYjdcf7HbxwaOvclgeGwI+is5VbRZigtSsm/jiUU=; b=R6ZT1a9kbCXfBBCWH0KbozQBbxSrKFLVThI7tHmzIdhP9cbTdtajfgNBZNZPWeAJIs7QPSy59yBreC984IdYc9GNAnMDW5rxZt5wj3a7YjLRIpyPC5CEddW0cnj6YsuJMBXOjCYcr7kYbEG2Q/gGcnSIOQfM7S+KweHLvE/iNl6uSNGD0tTy7mLgbD6ZH9dHsjLUWwJ+rOmk6TML5lidzTf3JplJmSrmM1Xi7KcpTgQyP++uVprfhgpOkQozpXny 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.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 Jun 2019 19:24:06 -0000 Date: 21 Jun 2019 15:24:06 -0400 Message-ID: From: "John R Levine" To: "Elizabeth Zwicky" Cc: "John R Levine" , dmarc@ietf.org, tki@tomki.com In-Reply-To: <0C6B5A70-6373-4DC1-9AB3-E0745F4D3364@otoh.org> References: <20190621184626.AE1B52016298ED@ary.qy> <8C941177-5B45-4B69-A2CB-C774BFB543FD@otoh.org> <0C6B5A70-6373-4DC1-9AB3-E0745F4D3364@otoh.org> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1745139005-1561145046=:53944" Archived-At: Subject: Re: [dmarc-ietf] spec nit - which DKIM to report 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, 21 Jun 2019 19:24:12 -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-1745139005-1561145046=:53944 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > The problem with that language is that >> o The identifier evaluated by DKIM and the DKIM result, if any > > is genuinely unclear. Often there are multiple identifiers. Does this mean I can pick any one of them? (That does not actually provide sufficient interoperability.) If there’s a specific one I should pick, which is it? How about we change identifier to identifiers? R's, John > On Jun 21, 2019, at 12:11 PM, John R Levine wrote: > >>> I believe they MUST contain any aligned DKIM signature regardless of validity and SHOULD contain an entry for each domain, selector, result triple. >> >> RFC 7489 says: >> >> The report SHOULD include the following data: >> >> o The DMARC policy discovered and applied, if any >> >> o The selected message disposition >> >> o The identifier evaluated by SPF and the SPF result, if any >> >> o The identifier evaluated by DKIM and the DKIM result, if any >> >> o For both DKIM and SPF, an indication of whether the identifier was >> in alignment >> >> (and a bunch of other stuff) >> >> I don't see any basis to change this, since as long as the report's format and syntax are correct, it'll interoperate. It may not have all the hints the report's recipient would like, but life is like that. >> >> R's, >> John > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1745139005-1561145046=:53944-- From nobody Fri Jun 21 12:54:56 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1A1200F9 for ; Fri, 21 Jun 2019 12:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEOyfJm6nzoG for ; Fri, 21 Jun 2019 12:54:52 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39F112009E for ; Fri, 21 Jun 2019 12:54:51 -0700 (PDT) Authentication-Results: mail.aegee.org/x5LJsli6002639; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1561146889; i=dkim+MSA-tls@aegee.org; r=y; bh=sn5lRExYtmjSlbbxFcUocFQmaQyBLOjYApGkdtke4Ys=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=XmqHTasbiE6EHP9hFVrlzUwhm9+gR9BXe0qf7z+RF8YOIr4OWsICJ+N0IHuSsICNR 3dDSmdkOp4odEthBV90bahYzM5biBXciNNxRb/MO5TOx8YmIBeizdBSphAQh+kjS/c +52woqPPTcdHZpEs+DnMtystgUHeIUlC/G4VKVizj4+n+zXS0cKvyi4uR5hPd9N0vM G1eI+Cb84JQE2/wTt7MrSW0iBBpjMquhD+25LxLZs1d0z507neqaQdbxVWQ9fPcqjp /csl3Rtv+57WqH17Yd25ylKMpaF7ttpHVP0hbk14Yt6GK8t1hmdC6dZQoeE2AZ4fwH GdtbaY75rcrAOUVmOLmAjpRPb0qxHN+8dYSlGRvoPr+EztHvsQc+0Y6C8+k+6J5AvN ax3KTNCMHFQ99Ig6CCtjVysmOF5uROF/K6bm17DRvGt8+9uZw7rfnjOXV+XqOXRwVm 14tkdxrHypNprpud2r5gC2BTVoqA/abb9kQAhQNA1Arjwt5cJK1QBC5xhQLp0iZSEp 0Aqlkp8OoUEA2ZfSNuqLKmWa30N/9I85PERpCBFJHxBZOH8DzL36LjqN69Ow4fCYQo 6JHyeiNpV67bmbmLoWkHBnsD3yD2O73+LW4Bs+SPH2N5c6Q6pwhgUGrGIE9p5TfnSj x+QldcYp/jPd6rp4idimGTgs= Authentication-Results: mail.aegee.org/x5LJsli6002639; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5LJsli6002639 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 21 Jun 2019 19:54:48 GMT Message-ID: <9ce26c4362b42bf2bf47beb81363775c942b441d.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Elizabeth Zwicky , John Levine Cc: dmarc@ietf.org, tki@tomki.com Date: Fri, 21 Jun 2019 19:54:47 +0000 In-Reply-To: <8C941177-5B45-4B69-A2CB-C774BFB543FD@otoh.org> References: <20190621184626.AE1B52016298ED@ary.qy> <8C941177-5B45-4B69-A2CB-C774BFB543FD@otoh.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] spec nit - which DKIM to report 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, 21 Jun 2019 19:54:55 -0000 Hello, what is the purpose of the aggregate reports (rua)? Regards Дилян On Fri, 2019-06-21 at 12:06 -0700, Elizabeth Zwicky wrote: > I believe they MUST contain any aligned DKIM signature regardless of validity and SHOULD contain an entry for each domain, selector, result triple. > > Elizabeth > > > On Jun 21, 2019, at 11:46 AM, John Levine wrote: > > > > In article <7cd366d2-ab8d-cce8-67ff-59b79183cd67@tomki.com> you write: > > > As mentioned by Elizabeth recently: (Elizabeth please chime in if this > > > doesn't capture your meaning) > > > > > > the spec does not define *which* DKIM signature should be reported in > > > the DMARC RUA created by a receiver. The proposed resolution to this is > > > that if the receiver does not provide the complete set of DKIM > > > signatures found, they should provide (in order of preference) > > > 1. a signature which passed DKIM in strict alignment with the From: > > > header domain > > > 2. a signature which passed DKIM in relaxed alignment with the From: > > > header domain > > > 3. some other signature that passed DKIM > > > 4. some other signature that didn't pass DKIM > > > > This seeems overcomplex. How about saying the reports SHOULD include > > all valid DKIM reports. If they can't, they can't, and I don't see > > any benefit in offering advice on how not to comply. > > > > > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Jun 21 18:04:29 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F66912017F for ; Fri, 21 Jun 2019 18:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tomki.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptUyl4SXOTHk for ; Fri, 21 Jun 2019 18:04:26 -0700 (PDT) Received: from athena.vistabroadband.net (athena.vistabroadband.net [69.39.252.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C07120073 for ; Fri, 21 Jun 2019 18:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomki.com; l=1655; q=dns/txt; s=tomki; t=1561165466; x=1561338266; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; z=To:=20dmarc@ietf.org|Cc:=20seth@sethblank.com|From:=20To mki=20|Subject:=20spec=20nit=20-=20subdoma ins=20reporting=20clarity|Message-ID:=20|Date:=20Fri,=2021=20Jun =202019=2018:04:28=20-0700|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit; bh=iw/l6FTIDbM2FF+XhQlCp8kJCnm9b7xUeLtBl7vrDXY=; b=KVm3SvBROig+uuDzMVHdGcARTvfhl8oh3kuTlJZ4pas5SH9WKg11T/j9 7fLcvoX6SXmd6h+NxWYS9t6JbBnGjPh0AZvvpfxvqI4qz8J3KVPL2C4Op u8fCN9KBLvo7RaftzHmjX4yHFHTPd7q3flkomzJBwhko844efPjIriZV7 LpoZcSfn9YvHoXTP+igaLLYIiI2KMVi/mtBMKCZ1ef6TMZe9iU5K978AH 0tIeH0bp2jVYRn/2bXS7cKsCSK7iCldWqcBFhhsGaHUxnY5ntRKr6Dj7u 17glf7u5FE4FEMXWXAnqA4vCdiFdUSpvM8ny4opPG7vokxS/qhw/Xgc1p g==; IronPort-SDR: sscXiAbaoOSND9nMY5oFsypsVcDFJCLDZbFJZZmbcoap8DYPnXcpiq7B9wopOj2Sw1iVYyMKlf 4QHWVa+AqADWmDIDC3aYBABw5g77BUj1/+acGMkHchhVPMvoqRVuCZNeOaWwMIHD296TJeDI2e 0wa/nuB9+mm0NwGp8BqbV8Dk5etImeNfEUS2ErBwpquuLVrV6cMgXYsa9aKuDHISImsZGzWT4r sYihfIGEZrAqeWRWJQkJzzKzHJhQeg0Ax6SGRz3Xi5+Zh6ZAzu535WyTx7Ou0N4qgbLxu5041J BZs= X-Filenames: X-SBRS: -10.0 X-recvListener: Inbound X-sendergroup: RELAYLIST X-remote-hostname: 75-105-60-135.cust.exede.net X-IronPort-AV: E=Sophos;i="5.63,402,1557212400"; d="scan'208";a="45039421" Received: from 75-105-60-135.cust.exede.net (HELO borage.ViaSatDomain) ([75.105.60.135]) by athena.vistabroadband.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2019 18:04:20 -0700 To: dmarc@ietf.org Cc: seth@sethblank.com From: Tomki Message-ID: Date: Fri, 21 Jun 2019 18:04:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] spec nit - subdomains reporting clarity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 01:04:28 -0000 The spec appears to be unclear on how subdomains are to be reported - ie most but not all implementations have performed this as intended, in the same XML as the top level domain (when the subdomain does not have its own DMARC TXT record) Cisco interpreted the current definition to mean that every subdomain seen should get its own XML file. (not just the ones with their own DMARC record) This results in every individual IronPort system [which has DMARC reporting enabled] generating hundreds to thousands of extra reports every day. This can result in corporate reporters like Paypal or Rolls Royce (IronPort users) sending as many reports in a given day as Google. The section which should be referred to in implementing a reporting engine is 7.2 https://tools.ietf.org/html/rfc7489#section-7.2 The only relevant bullet that I find here is " The report SHOULD include the following data:" ... "Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy" In trying to find out why Cisco implemented their reporting in the way that they did, I've actually had a hard time understanding how others understood that bullet point well enough - I can only imagine that everybody just implemented by following examples of existing implementations. A suggested rewording for that bullet point: " Data for each Domain Owner's subdomains as separate records in a report titled for the Organizational Domain, unless there is an explicit subdomain policy - in which case a standalone report is generated for that subdomain" --Tomki From nobody Wed Jun 26 13:14:24 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFCF120114 for ; Wed, 26 Jun 2019 13:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhrJWtju-4MR for ; Wed, 26 Jun 2019 13:14:19 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 7E0931200F1 for ; Wed, 26 Jun 2019 13:14:18 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id 136so2446250lfa.8 for ; Wed, 26 Jun 2019 13:14:18 -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=DXFytX3SeLWlGRTgzZ7SEiHTdUMugg9VPcR/pTVW3R8=; b=nimhew7sM3R9NgfYQWfC5zxE3aDf+FbyEt1R6D+uUFokMVXFekyvBmsm7XcIroN+Lg svXlAElhzNqx+1IqoGt90WpIfVFBcT8KHkADZe/nrQM1roxbFQ48WpC0dA4/G9e67wNm q5yDfPUOfpaiqz2mQ+KeEQbFR+VS1CCLL6DoxdFwSzauQUCiIxxj5v+VvkMnpfXUrmwn LAfX4KJtkt5IJ1NBrqpo1ZoOauwTBIbGQiL50GMPCMDit0D/qiQiT07NVpFAaJqtI4EA 4kwLnNm7legX+nfvIs9QqfXe/XoLg//jgqfk6tlLV0UQqexxAivwe1GkY4bIXbdoreSm lsCA== 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=DXFytX3SeLWlGRTgzZ7SEiHTdUMugg9VPcR/pTVW3R8=; b=rQ2VKcKDySa3ISM8WTdYzUobGXcrHBr3VADCQd00aGNqD1ZDLbOeXDf6WBs/alylQq U13W5xph4jr3pbn0nQd1NhkE7dwY/+gAhfj3fGhMz2nsg6TEjUN4iMxGcWxPh1QbVR+7 svOIOC9fAt0UHGU7xDTQjnblDMuYTXdRbtQfDIuNWGgc2TK/AZdLvyjSFyFkXd6IhgKb zXoEz5MnCIk7B+26xowjTLC4WYaxTQH0kKnezhZhwRtD7MqyxpLtQzrowbCerMPptAVL BUGZ50/OSsi9DsUpp2xjzsWKvQXLNzOauO1zqp95S4cvnTelRQDF2T6+W8KxAxTrRJ5q IOkQ== X-Gm-Message-State: APjAAAXwtyUaBgvmq5Ek8f1Qd4NyxcJtVBZQSNDAL2e3StXoQVPmBHcX wprO6idv4Rba3mDr/2JCSa45xaLIyTKTuXBBPqp5jQ== X-Google-Smtp-Source: APXvYqwOMWANh2v5b5MaEHW/x5RATLknUB9d/SUioF5VWjznCePxbBTbNcVaK8ywu5P5pVfnY9i3QzKh4rtE7Q5jFno= X-Received: by 2002:ac2:546a:: with SMTP id e10mr3698554lfn.75.1561580056414; Wed, 26 Jun 2019 13:14:16 -0700 (PDT) MIME-Version: 1.0 References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580> <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net> <22952181.EZtIpUVr24@l5580> In-Reply-To: <22952181.EZtIpUVr24@l5580> From: "Murray S. Kucherawy" Date: Wed, 26 Jun 2019 13:14:04 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008d0f1e058c3fb02d" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.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: Wed, 26 Jun 2019 20:14:22 -0000 --0000000000008d0f1e058c3fb02d Content-Type: text/plain; charset="UTF-8" Just came in to start WGLC and saw this. If you have the momentum to do an update now (like today), feel free. Otherwise I'll kick off WGLC shortly. On Mon, Jun 10, 2019 at 3:26 PM Scott Kitterman wrote: > On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote: > > > On May 27, 2019, at 6:59 PM, Scott Kitterman > wrote: > > > > > > On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org wrote: > > >> 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-04.txt > > >> Pages : 11 > > >> Date : 2019-05-27 > > > > > > There isn't much to this update. It corrects one typo and reverts the > RUF > > > MUST NOT as discussed on the list. As far as I'm aware there are no > other > > > pending issues in the WG with the draft. > > > > Hi Scott, I've reviewed the doc and have made some comments. Feel free to > > dispose of them as you will. > > > > I had a hard time with the introduction. "sets of domains within a single > > organization" and "lower level policy" left me not knowing what I was > > reading. I'm unhappy just complaining, so I took a stab at this > admittedly > > difficult section. The original: > > > > DMARC [RFC7489] provides a mechanism for publishing organizational > > policy information to email receivers. DMARC [RFC7489] allows policy > > to be specified for both individual domains and sets of domains > > within a single organization. For domains above the organizational > > level in the DNS tree, policy can only be published for the exact > > domain. There is no method available to such domains to express > > lower level policy or receive feedback reporting for sets of domains. > > This prevents policy application to non-existent domains and > > identification of domain abuse in email, which can be important for > > brand and consumer protection. > > > > My stab: > > > > DMARC [RFC7489] provides a mechanism for publishing organizational > > policy information to email receivers. DMARC [RFC7489] allows policy > > to be specified for both individual domains and for organizational > > domains and their sub-domains > > within a single organization. For TLDs and domains that exist between > > TLDs and organization level domains, policy can only be published for > the > > exact domain. No method is available for such domains to express > > policy or receive feedback reporting for sub-domains. > > This missing method allows for the abuse of non-existent > > organizational-level domains and prevents identification of domain abuse > in > > email. > > > > > > The example section doesn't read like the rest of the draft and was hard > for > > me to read through. Original: > > > > This would provide policy and feedback for mail sent from > > @gov.example, but not @tax.gov.example and there is no way to publish > > an organizational level policy that would do so. While, in theory, > > receivers could reject mail from non-existent domains, not all > > receivers do so. Non-existence of the sending domain can be a factor > > in a mail delivery decision, but is not generally treated as > > definitive on its own. > > > > Again my stab: > > > > This DMARC record provides policy and a reporting destination for mail > > sent from @gov.example. However, due to DMARC's current method of > > discovering and applying policy at the organizational domain level, the > > non-existent organizational domain of @tax.gov.example does not and > cannot > > fall under a DMARC policy. > > > > > > I don't have too much more, I just got just caught up in the initial > read. > > This paragraph contains a construct that was confusing to me: > > > > This memo provides a simple extension to DMARC [RFC7489] to allow > > operators of Public Suffix Domains (PSDs) to express policy for > > groups of subdomains, extends the DMARC [RFC7489] policy query > > functionality to detect and process such a policy, describes receiver > > feedback for such policies, and provides controls to mitigate > > potential privacy considerations associated with this extension. > > > > ^^^ why "groups of subdomains" and not just "subdomains"? One step > further, > > why not "express policy at the level of the PSD that covers all > > organizational domains that do not explicitly publish DMARC records"? > > > > > > OK, two more things: > > > > 2.3. Longest PSD > > > > Organizational Domain (DMARC [RFC7489] Section 3.2) with one label > > removed. > > > > ^^^ "one left-most label removed"? > > > > > > Last thing: Security considerations might call out DNS cache poisoning > as a > > way to get reports for a PSD. Applies to vanilla DMARC too, but the scope > > and potential breadth of information with PSD-DMARC is really > interesting. > > I imagine an attack that gets .COM listed into the PSD Registry for a > > specific report generator.. combined with cache poisoning and the poor > > report generator would probably explode at best. > > Thanks. I think those are all good comments. I can crank out an update > or > wait until after WGLC as the chairs prefer. > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000008d0f1e058c3fb02d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just came in to start WGLC and saw this.=C2=A0 If you have= the momentum to do an update now (like today), feel free.=C2=A0 Otherwise = I'll kick off WGLC shortly.

On Mon, Jun 10, 2019 at 3:26 PM Scott Ki= tterman <sklist@kitterman.com> wrote:
On = Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote:
> > On May 27, 2019, at 6:59 PM, Scott Kitterman <sklist@kitterman.com> wrot= e:
> >
> > On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org wrote:
> >> A New Internet-Draft is available from the on-line Internet-D= rafts
> >> directories. This draft is a work item of the Domain-based Me= ssage
> >> Authentication, Reporting & Conformance WG of the IETF. > >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: DMARC (Domain-based Message Authentication,
> >>
> >> Reporting, and Conformance) Extension For PSDs (Public Suffix= Domains)
> >> Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Scott Kitterman > >>
> >>=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf= -dmarc-psd-04.txt
> >>=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = 11
> >>=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = 2019-05-27
> >
> > There isn't much to this update.=C2=A0 It corrects one typo a= nd reverts the RUF
> > MUST NOT as discussed on the list.=C2=A0 As far as I'm aware = there are no other
> > pending issues in the WG with the draft.
>
> Hi Scott, I've reviewed the doc and have made some comments. Feel = free to
> dispose of them as you will.
>
> I had a hard time with the introduction. "sets of domains within = a single
> organization" and "lower level policy" left me not know= ing what I was
> reading. I'm unhappy just complaining, so I took a stab at this ad= mittedly
> difficult section. The original:
>
>=C2=A0 =C2=A0 DMARC [RFC7489] provides a mechanism for publishing organ= izational
>=C2=A0 =C2=A0 policy information to email receivers.=C2=A0 DMARC [RFC74= 89] allows policy
>=C2=A0 =C2=A0 to be specified for both individual domains and sets of d= omains
>=C2=A0 =C2=A0 within a single organization.=C2=A0 For domains above the= organizational
>=C2=A0 =C2=A0 level in the DNS tree, policy can only be published for t= he exact
>=C2=A0 =C2=A0 domain.=C2=A0 There is no method available to such domain= s to express
>=C2=A0 =C2=A0 lower level policy or receive feedback reporting for sets= of domains.
>=C2=A0 =C2=A0 This prevents policy application to non-existent domains = and
>=C2=A0 =C2=A0 identification of domain abuse in email, which can be imp= ortant for
>=C2=A0 =C2=A0 brand and consumer protection.
>
> My stab:
>
>=C2=A0 =C2=A0 DMARC [RFC7489] provides a mechanism for publishing organ= izational
>=C2=A0 =C2=A0 policy information to email receivers.=C2=A0 DMARC [RFC74= 89] allows policy
>=C2=A0 =C2=A0 to be specified for both individual domains and for organ= izational
>=C2=A0 =C2=A0 domains and their sub-domains
>=C2=A0 =C2=A0 within a single organization.=C2=A0 For TLDs and domains = that exist between
>=C2=A0 =C2=A0 TLDs and organization level domains, policy can only be p= ublished for the
> exact domain.=C2=A0 No method is available for such domains to express=
>=C2=A0 =C2=A0 policy or receive feedback reporting for sub-domains.
>=C2=A0 =C2=A0 This missing method allows for the abuse of non-existent<= br> > organizational-level domains and prevents identification of domain abu= se in
> email.
>
>
> The example section doesn't read like the rest of the draft and wa= s hard for
> me to read through. Original:
>
>=C2=A0 =C2=A0 This would provide policy and feedback for mail sent from=
>=C2=A0 =C2=A0 @gov.example, but not @tax.gov.example and there is no wa= y to publish
>=C2=A0 =C2=A0 an organizational level policy that would do so.=C2=A0 Wh= ile, in theory,
>=C2=A0 =C2=A0 receivers could reject mail from non-existent domains, no= t all
>=C2=A0 =C2=A0 receivers do so.=C2=A0 Non-existence of the sending domai= n can be a factor
>=C2=A0 =C2=A0 in a mail delivery decision, but is not generally treated= as
>=C2=A0 =C2=A0 definitive on its own.
>
> Again my stab:
>
>=C2=A0 =C2=A0 This DMARC record provides policy and a reporting destina= tion for mail
> sent from @gov.example. However, due to DMARC's current method of<= br> > discovering and applying policy at the organizational domain level, th= e
> non-existent organizational domain of @tax.gov.example does not and ca= nnot
> fall under a DMARC policy.
>
>
> I don't have too much more, I just got just caught up in the initi= al read.
> This paragraph contains a construct that was confusing to me:
>
>=C2=A0 =C2=A0 This memo provides a simple extension to DMARC [RFC7489] = to allow
>=C2=A0 =C2=A0 operators of Public Suffix Domains (PSDs) to express poli= cy for
>=C2=A0 =C2=A0 groups of subdomains, extends the DMARC [RFC7489] policy = query
>=C2=A0 =C2=A0 functionality to detect and process such a policy, descri= bes receiver
>=C2=A0 =C2=A0 feedback for such policies, and provides controls to miti= gate
>=C2=A0 =C2=A0 potential privacy considerations associated with this ext= ension.
>
> ^^^ why "groups of subdomains" and not just "subdomains= "? One step further,
> why not "express policy at the level of the PSD that covers all > organizational domains that do not explicitly publish DMARC records&qu= ot;?
>
>
> OK, two more things:
>
> 2.3.=C2=A0 Longest PSD
>
>=C2=A0 =C2=A0 Organizational Domain (DMARC [RFC7489] Section 3.2) with = one label
>=C2=A0 =C2=A0 removed.
>
> ^^^ "one left-most label removed"?
>
>
> Last thing: Security considerations might call out DNS cache poisoning= as a
> way to get reports for a PSD. Applies to vanilla DMARC too, but the sc= ope
> and potential breadth of information with PSD-DMARC is really interest= ing.
> I imagine an attack that gets .COM listed into the PSD Registry for a<= br> > specific report generator.. combined with cache poisoning and the poor=
> report generator would probably explode at best.

Thanks.=C2=A0 I think those are all good comments.=C2=A0 I can crank out an= update or
wait until after WGLC as the chairs prefer.

Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000008d0f1e058c3fb02d-- From nobody Wed Jun 26 13:28:04 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1CB12036C for ; Wed, 26 Jun 2019 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_UOwOXs-x7b for ; Wed, 26 Jun 2019 13:28:01 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 C6C2212008B for ; Wed, 26 Jun 2019 13:28:00 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id u10so2458751lfm.12 for ; Wed, 26 Jun 2019 13:28:00 -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=I+2RJKY75hAEFCu7fkQi2vsVz7Ef4VniWjX1SvzyWog=; b=HY8bRx4aX+WXPGj2tptCOonks35n5EW+czm1yA0d+36mOj7n3qA4hnpRo/CFEb+dFG cXVl2tlML8fVvPp2UV+ZONnLqRe8IJBv7EXcWRBJfzk6x47knmG41YHj/88r+MvlNJC9 5LDPN8tMy9EyD3grGtpoAXkQYPQq5QQfIs+U1RAzduaXqbejkpd7sXvC7B3mTru4EGoR ZVBFkdPN7tixPgh+F2w/VtxCESS+gZMKbdPGVIfJ7Vky4ZEgbWMhCFOZBtVqTQWM6+KU VT7cRRjLgoBgGxcHoVwdY18DcvIAGMlfx11AXS+Az6+ILXLuMVxHRUA7qmS+OdGym4/I +spw== 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=I+2RJKY75hAEFCu7fkQi2vsVz7Ef4VniWjX1SvzyWog=; b=SkLPDrKww5aJkQrFeaXEib2Sor4Yz07FtjfUqJ8fie2XaD9S3zI4TDMcxvg2vlQwse DfDk12/im7l6Ev3js1mo090Pwq0CQZPf5WcxqbtXcC1cXg5ia5MxHy4LyNzpBJ2/Ck0v jD1TLuDjlfW62xUVoXZTXmnsa+4VYiLjxLSQcJYGyzCdcZkCmwUUxvn2KnxPzkn7ZgF5 1zF2zuWN4N5z5/7EYitbqVpE7Vu2o2TBHlWhTqT+UnT7aD3CYRk8+uiY8/eB9mZxqAeN ZDRbuVoZs+0MdAnG2N9D7h5fPo2ucLo5mF+xdg0RCLkkfXO45cYS4OqN9NhypgnpRU6e KAqw== X-Gm-Message-State: APjAAAXcgT8cnjGmss5Rm0W7uCirzxYzBiGmY4aZjjhWGb5pK8hK2zRQ SCSD882eupQCbv0wyjgTJC2aIOwFXTZ56HsFCHU= X-Google-Smtp-Source: APXvYqx0JGxh00AjmCSXixv49aiTKUf+s89SozwnrQXbnZhXZM62PYRggkjTmYBbPO5QVeQ/ITmWsoftFcAKyhYsRhI= X-Received: by 2002:a19:4c05:: with SMTP id z5mr31310lfa.5.1561580878612; Wed, 26 Jun 2019 13:27:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 26 Jun 2019 13:27:46 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008ecdea058c3fe16c" Archived-At: Subject: Re: [dmarc-ietf] New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 20:28:03 -0000 --0000000000008ecdea058c3fe16c Content-Type: text/plain; charset="UTF-8" On Tue, Jun 4, 2019 at 4:01 AM Alessandro Vesely wrote: > Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF's > reject-on-fail. The score attributed to the sender by a trusted DNSWL is > also > useful after DATA, thence the need to store that value for downstream > filters. > > However, as an authentication method, a DNSWL TXT response can provide a > domain > name, which is possibly aligned with From:. In that sense, this method > might > be of interest for this WG. Probably not, but I felt compelled to make > sure > before trying independent submission. (Already tried ART.) The I-D is > here: > https://tools.ietf.org/html/draft-vesely-authmethod-dnswl > With my Designated Expert hat on and co-chair hat off, a procedural point here: The IANA registry for these is Expert Review, which means you don't have to publish an RFC to get it registered. You can, but it's not necessary if your registration request can sufficiently describe what you're doing. See RFC8601 Section 6.2, fourth paragraph. -MSK --0000000000008ecdea058c3fe16c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2019 at 4:01 AM Alessandro= Vesely <vesely@tana.it> wrote:=
Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF&= #39;s
reject-on-fail.=C2=A0 The score attributed to the sender by a trusted DNSWL= is also
useful after DATA, thence the need to store that value for downstream filte= rs.

However, as an authentication method, a DNSWL TXT response can provide a do= main
name, which is possibly aligned with From:.=C2=A0 In that sense, this metho= d might
be of interest for this WG.=C2=A0 Probably not, but I felt compelled to mak= e sure
before trying independent submission.=C2=A0 (Already tried ART.)=C2=A0 The = I-D is here:
https://tools.ietf.org/html/draft-vesely-= authmethod-dnswl

With my Designated= Expert hat on and co-chair hat off, a procedural point here:

=
The IANA registry for these is Expert Review, which means you don'= t have to publish an RFC to get it registered.=C2=A0 You can, but it's = not necessary if your registration request can sufficiently describe what y= ou're doing.=C2=A0 See RFC8601 Section 6.2, fourth paragraph.

-MSK
--0000000000008ecdea058c3fe16c-- From nobody Wed Jun 26 13:49:31 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB5A1203A6 for ; Wed, 26 Jun 2019 13:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK4KfJbxdZmY for ; Wed, 26 Jun 2019 13:49:27 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 BAB3612018B for ; Wed, 26 Jun 2019 13:49:26 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id h10so32149ljg.0 for ; Wed, 26 Jun 2019 13:49:26 -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=qnZDWcAPza+u2ebZRv7b+atRWOEfQ4P3Loei7XCWJls=; b=f3UbqdO6V3qDqsW9YDqeOoHKLegQeh1waNKrEn/6H1WRAWXHuE+soe1HRX9s9tnJ+7 cKm8dngoOdhL3knLgVkZRxSMM8nQNBoMDhDYSXsNTWB5z02oroi7OGGnNd2PY8CFdFXZ eWnbAbxsRfkuGD0cgAL6TOntssSE5RTbHp5Ocw2N6tBWBGhufy9Fl5M3bKdhMHeL4R63 oUokZZYrgGrVroehe2mm/50Ul7FUUecmB4NAM+6ajLrf4juNwDZ92hSEdM9Ty7/hQN6p 47ZPue8n7NjtkNiBLPwfM2zi6DEmhreWhVQyK6Wfjyq0QLKmsaXD+zyQosITykXkXnzq 1IvA== 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=qnZDWcAPza+u2ebZRv7b+atRWOEfQ4P3Loei7XCWJls=; b=laLcF+AlFr27sb95C01DBDX4PPYNRpDC+aUETYLnPx0BB8IWIBqfVIftpnfsgvT5Dp thtegI7xlbvkDzptw1rXGpJFDJoH43RanVDoRBBQ8AkkK8VBo350PRDv0tm0To1MPdJb 3YR5D9wbXePxmWm0oA4hIXEmqBQ1uCdNqhx1rGelwLvBVEruj91sScmbcOVo/7r0oMgt lzHhwgUOOfSmXlwqInEL/0MsswPU4iRhRcDpxE5giPqmlQC30bG//Vh39cBL6gxoKcsn 3k5IPF3/eI/vHs4m7NSX1pKsdv1ohgRRiK+6cwft6TIqaf6jawmih1ieCa2uZymXkp5o Zv8g== X-Gm-Message-State: APjAAAVwP0KVh51EgSLwC1Nwxbx4k8sgm2MCafwwmAgGhvGOQoLzU60A OeCzgfpWCVW5H1FBw2cRU51pZNb69OaKkP5fxjiMC/c4 X-Google-Smtp-Source: APXvYqwL9p+zoVuaAI0VsWNL7KDJLz10choNArrH+uoh706gvXWqrfaIQXTEkX78bIM+097KJpnsNJc3sdYJdIDvfPk= X-Received: by 2002:a2e:7c14:: with SMTP id x20mr179750ljc.56.1561582164726; Wed, 26 Jun 2019 13:49:24 -0700 (PDT) MIME-Version: 1.0 References: <5130c7f40b444b97ab95864e6fc243ce@verisign.com> <2221039.c73XDibtHi@l5580> In-Reply-To: <2221039.c73XDibtHi@l5580> From: "Murray S. Kucherawy" Date: Wed, 26 Jun 2019 13:49:13 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000375843058c402e12" Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 26 Jun 2019 20:49:30 -0000 --000000000000375843058c402e12 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 10, 2019 at 3:31 PM Scott Kitterman wrote: > > >On Thursday, June 6, 2019 at 1:12 PM EDT Scott Hollenbeck wrote: > > >I recently had a chance to read through draft-ietf-dmarc-psd. If I > > >understand it correctly (and I'm not sure that I do), the document > > >suggests that it's possible for a TLD like ".com" >to be a PSD and a TXT > > >record like "_dmarc.com" can be published in the com > > >zone. I found this part of the draft confusing because it's not possible > > >to add TXT records like that >to the com zone. It might help to > explicitly > > >note somewhere (perhaps in Section 2.2) that there may be policy > > >restrictions in place that disallow the publication of DMARC policy > > >>records in some DNS zones, including some top-level domain zones. > As I understand it, we're in an interesting position here: ".com" can't have a TXT record in that zone due to ICANN policy, and this ICANN policy won't change without a (published or imminent) RFC that suggests allowing such records would be of benefit to the community. So the publication of this even at experimental might obviate the need for such text in the document. Given your concern, I think we're talking about adding text that says "There may be operational constraints that prevent any given operator's participation in this experiment." But isn't that an implicit caveat of all experiments? On the other hand, perhaps the largest benefit would be from the restricted TLD operators if they were allowed to do so. > Right now, PSD DMARC cannot be deployed > > ubiquitously. That reality should not be overlooked. > This part I agree with; by pointing out that this cannot be widely deployed right away, we are highlighting that the results of the experiment could be understated due to the restrictions Scott H. has identified. I see your point, but I think it's probably out of scope. This is an IETF > document and such restrictions are outside the IETF's control. Also, keep > in > mind that once an RFC is published, it is immutable. If that guidance > changes, then there would be no way to correct the document without > spinning > up a whole new RFC process. > I think it might be beneficial to point out somewhere in the document that today's operational reality prevents this experiment from being deployed globally. However, if the experiment shows that PSD solves a real problem at a large scale, it would be fodder for appropriate policy changes outside of the IETF that would permit its ubiquitous deployment. > Is there a public, stable reference that describes the restrictions? If > so, > it might make sense to reference it. If we can, I think that would be > much > better than 'hard coding' the current external policy in an RFC. > I concur. Does anyone know of such a policy statement from ICANN? I don't recall it being present in, say, any of the DNS RFCs, but there are so many of those now... -MSK --000000000000375843058c402e12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2019 at 3:31 PM Scott Kit= terman <sklist@kitterman.com= > wrote:
> >On Thursday, June 6, 2019 at 1:12 PM EDT Sc= ott Hollenbeck wrote:
> >I recently had a chance to read through draft-ietf-dmarc-psd. If I=
> >understand it correctly (and I'm not sure that I do), the docu= ment
> >suggests that it's possible for a TLD like ".com" &g= t;to be a PSD and a TXT
> >record like "_dmarc.com<http://dmarc.com/>" can be publishe= d in the com
> >zone. I found this part of the draft confusing because it's no= t possible
> >to add TXT records like that >to the com zone. It might help to= explicitly
> >note somewhere (perhaps in Section 2.2) that there may be policy > >restrictions in place that disallow the publication of DMARC polic= y
> >>records in some DNS zones, including some top-level domain zon= es.

As I understand it, we're in an= interesting position here: ".com" can't have a TXT record in= that zone due to ICANN policy, and this ICANN policy won't change with= out a (published or imminent) RFC that suggests allowing such records would= be of benefit to the community.=C2=A0 So the publication of this even at e= xperimental might obviate the need for such text in the document.

Given your concern, I think we're talking about adding = text that says "There may be operational constraints that prevent any = given operator's participation in this experiment."=C2=A0 But isn&= #39;t that an implicit caveat of all experiments?

On the = other hand, perhaps the largest benefit would be from the restricted TLD op= erators if they were allowed to do so.

> Right now, PSD DMARC cannot be deployed
> ubiquitously. That reality should not be overlooked.
<= div>
This part I agree with; by pointing out that this cannot= be widely deployed right away, we are highlighting that the results of the= experiment could be understated due to the restrictions Scott H. has ident= ified.

I see your point, but I think it's probably out of scope.=C2=A0 This is= an IETF
document and such restrictions are outside the IETF's control.=C2=A0 Al= so, keep in
mind that once an RFC is published, it is immutable.=C2=A0 If that guidance=
changes, then there would be no way to correct the document without spinnin= g
up a whole new RFC process.

I thin= k it might be beneficial to point out somewhere in the=20 document that today's operational reality prevents this experiment from= being=20 deployed globally.=C2=A0 However, if the experiment shows that PSD solves a= =20 real problem at a large scale, it would be fodder for appropriate policy changes outside of the IETF that would permit its ubiquitous deployment.
=C2=A0
Is there a public, stable reference that describes the restrictions?=C2=A0 = If so,
it might make sense to reference it.=C2=A0 If we can, I think that would be= much
better than 'hard coding' the current external policy in an RFC.

I concur.=C2=A0 Does anyone know of such = a policy statement from ICANN?=C2=A0 I don't recall it being present in= , say, any of the DNS RFCs, but there are so many of those now...

-MSK
--000000000000375843058c402e12-- From nobody Wed Jun 26 14:08:27 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9296F12003F for ; Wed, 26 Jun 2019 14:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhKiA6i4a6qr for ; Wed, 26 Jun 2019 14:08:24 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77371200F1 for ; Wed, 26 Jun 2019 14:08:23 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id m23so22810lje.12 for ; Wed, 26 Jun 2019 14:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FDcHhquc6+GynzeB2SGojQp7CcsaCs7xkkLh6Eh3dzg=; b=gor605i/VY76eFffCJesF6iCLgRjKDmN2aJ+JzR3Kop+Isqu1Hg5HQVqdDxRj0Ub9W 36yzoPup1fH0QLvUF0MwuLA54VRw2TDUPP2115EbwXpL+iCzCGa08IAbQ0pq2yZ4fwKi JtgDljookipgK2LU99iBsYQ8+fG1Y9Agr4Ch1dcWKS7ioJfx5GxfNhl8NIDk2irpbxuf UpIq/8dXF5klu/A3JH/+eSehsZBEzj6aJaFIb6Vx9haDQMfdc7yX40E5zFxW+1ap9Dn5 U9cushhdMywvvrKIOoAZ9DSWk6eMay8o9SU0GF08oM3XWUwu1/s7xGwrm0YG6TZnQa3G 7RAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FDcHhquc6+GynzeB2SGojQp7CcsaCs7xkkLh6Eh3dzg=; b=cfhITRJa4SYN8SWY81HvopU+ZQ7k1eXpEiCukVCRcBWqUycKhh7gc8X5IreKM06+hw EQKJifaSU7kY8ynzXU+6x9bD49Zq/PAvd0HQcri7z+ur/8xxbfprngBs5l0LHAnG/H8H deR5xS8XZ0nYVusl+s90Mcagq0DOIKahRH/I3gWbOuLYnKMCxbKMGrAeERZR8jWfTfFu klfpCVc6dt3M1CaZfhEKoUDEZW6jxhwpk6s3toGSaGLjQYEpqBMZdCf1xKAu+mYpaNJ7 rqKbywxt+1cZUZLSgrQB9BCw68NrM5zhseosDdB6capGMBtPQFa1PsmJruemZ928HTz9 zazw== X-Gm-Message-State: APjAAAVsKc+pADZH2rVmHMGsll31UTasXo/p5BFK3OGDXT1Q8ihqixEo zHH4iaPkvHNRrOLbR5xHUS2uUb6oYJ41M+RxjaLfyFys X-Google-Smtp-Source: APXvYqxjeQBO+WWEIMeNCKqjySdQf9v3qRARuVIy2aTe9MnxZEJeUD87u4vhuYC+lBn434bIjbdGCtD2M8eLe91vEs4= X-Received: by 2002:a2e:870f:: with SMTP id m15mr182045lji.223.1561583301649; Wed, 26 Jun 2019 14:08:21 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Wed, 26 Jun 2019 14:08:10 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fb6923058c4071c9" Archived-At: Subject: [dmarc-ietf] Working Group Last Call: 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, 26 Jun 2019 21:08:27 -0000 --000000000000fb6923058c4071c9 Content-Type: text/plain; charset="UTF-8" This message begins Working Group Last Call for draft-ietf-dmarc-psd, which is currently at version 04. An 05 may appear shortly with some text changes that were previously discussed on the list; these do not include any technical changes (I believe) so the author is free to update with only those changes as planned. Please review the document and submit your feedback by Wednesday, July 17th. We would ideally like to have enough responses to support our claim to the IESG that the document clearly has working group consensus. Note that we will be in pre-meeting draft embargo at that time so a new version dealing with any feeback cannot appear until IETF 105 begins on the 22nd. I'm planning to do my own review as the document shepherd with an eye toward consumption by readers with only a passing familiarity with DMARC. If anyone wants to join me in looking at it through that lens, you'd be welcome. -MSK, co-chairin' --000000000000fb6923058c4071c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This message begins Working Group Last Call for = draft-ietf-dmarc-psd, which is currently at version 04.=C2=A0 An 05 may app= ear shortly with some text changes that were previously discussed on the li= st; these do not include any technical changes (I believe) so the author is= free to update with only those changes as planned.

Please rev= iew the document and submit your feedback by Wednesday, July 17th.=C2=A0 We= would ideally like to have enough responses to support our claim to the IE= SG that the document clearly has working group consensus.

Note that = we will be in pre-meeting draft embargo at that time so a new version deali= ng with any feeback cannot appear until IETF 105 begins on the 22nd.
I'm planning to do my own review as the document shepherd w= ith an eye toward consumption by readers with only a passing familiarity wi= th DMARC.=C2=A0 If anyone wants to join me in looking at it through that le= ns, you'd be welcome.

-MSK, co-chairin'
--000000000000fb6923058c4071c9-- From nobody Wed Jun 26 14:21:33 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB071202B4 for ; Wed, 26 Jun 2019 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=valimail.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 J1Nzy2sG0BJz for ; Wed, 26 Jun 2019 14:21:28 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 C927B120379 for ; Wed, 26 Jun 2019 14:21:27 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id n9so11001wru.0 for ; Wed, 26 Jun 2019 14:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dmeUcjbhOr88PcFb/G96C/Wzfa21eHXOU3a5KyMLKzk=; b=XgkjU42P0SnRE6+Uto+6ZmGXyt7SZtVOjuuppKO3EUx+nZpm1FcBbF+DRH8hRik22z Bjj94tcue/x9HQYdyz+0RJzIi3LymfYgHLx/EvDkTX6o+fTdvF8Ik0zDnR8MMKqSheZJ oKKOBa0D1SJ5uI3dyNcdoAeQ2yhuC4Y+G3hPO146E4N/M1zIrTjemDGzhwm8pPWFsw9f 99Somso485dIn5GILu7uzotHN1oGn+nvThhs3r5ZHZ+tcRSFUoeFB6bbtZkewDXnjUmD tbFFDrKzgae7ukWr+2pUwD0iSj7w02Rt/Kj4SeQb66qYASfSWIYGGlF8niEhhAXMGwMZ K1Gg== 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=dmeUcjbhOr88PcFb/G96C/Wzfa21eHXOU3a5KyMLKzk=; b=nGKc6WNRzICkeFgE4UtufnH4OLmvoXqozH1YxDXJ0Qu7tTbhTg9DQ2yBKlFq9bOp7s Yz9Ef5mW341zhgBdb4F5pSIEefPlBHCg46Hxd1yQu48IW60RcFcsnL9T3Bsfj7RzGKrp ISzN9yMSk6eHjr4YJdWjpkpDj32ngikgzuvhcBTnefukm3upVuk1mc4GN+KDD/q6HrMs Bvr4uacbn//YA1N61PzgjRyEZtmgHMLu3K756XRk15girGt/fZJ8rQqwPf8crV8YBd12 vWySDe9fOenJDfZ/owbEShFSYl3DlIDQhvt6GujLeZgP+iuIT0x3pYGTKTHUX6jE+Yqn /5pw== X-Gm-Message-State: APjAAAVKBidlTalRrPQ47tK7HspqSjUIFSpYYYaWOWBMzigsbtj5QFSK 2NUKHpZrgsM4xMOX+yyvwcvLJAZZY0De3b6s6tvQGsdrHQk= X-Google-Smtp-Source: APXvYqxEoO+hYfGGXjqpFo27/bG7jBE7eLphg9o8yatE3uMApWBuPMKM5OT+O38P7dl4mGGrTpWLb4sayLqKg+D5g88= X-Received: by 2002:adf:cf0a:: with SMTP id o10mr5174150wrj.37.1561584085764; Wed, 26 Jun 2019 14:21:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Wed, 26 Jun 2019 14:21:14 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b82045058c40a00b" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 26 Jun 2019 21:21:32 -0000 --000000000000b82045058c40a00b Content-Type: text/plain; charset="UTF-8" As Secretary, there are three items that have not yet reached consensus that must be resolved during WGLC: 1. What further context is needed in the introduction 2. If explicit call outs to ICANN/limited operator capacity to implement are needed 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs Seth On Wed, Jun 26, 2019 at 2:08 PM Murray S. Kucherawy wrote: > This message begins Working Group Last Call for draft-ietf-dmarc-psd, > which is currently at version 04. An 05 may appear shortly with some text > changes that were previously discussed on the list; these do not include > any technical changes (I believe) so the author is free to update with only > those changes as planned. > > Please review the document and submit your feedback by Wednesday, July > 17th. We would ideally like to have enough responses to support our claim > to the IESG that the document clearly has working group consensus. > > Note that we will be in pre-meeting draft embargo at that time so a new > version dealing with any feeback cannot appear until IETF 105 begins on the > 22nd. > > I'm planning to do my own review as the document shepherd with an eye > toward consumption by readers with only a passing familiarity with DMARC. > If anyone wants to join me in looking at it through that lens, you'd be > welcome. > > -MSK, co-chairin' > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | Director, Industry Initiatives *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000b82045058c40a00b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Secretary, there are three items that have not yet reac= hed consensus that must be resolved during WGLC:

1. What furth= er context is needed in the introduction
2. If explicit call outs= to ICANN/limited operator capacity to implement are needed
3= . If an np=3D tag is needed to allow PSD functioning for only NXDOMAINs

Seth

=
On Wed, Jun 26, 2019 at 2:08 PM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
This message begins Working Group Last Call fo= r draft-ietf-dmarc-psd, which is currently at version 04.=C2=A0 An 05 may a= ppear shortly with some text changes that were previously discussed on the = list; these do not include any technical changes (I believe) so the author = is free to update with only those changes as planned.

Please r= eview the document and submit your feedback by Wednesday, July 17th.=C2=A0 = We would ideally like to have enough responses to support our claim to the = IESG that the document clearly has working group consensus.

Note tha= t we will be in pre-meeting draft embargo at that time so a new version dea= ling with any feeback cannot appear until IETF 105 begins on the 22nd.
<= br>
I'm planning to do my own review as the document shepherd= with an eye toward consumption by readers with only a passing familiarity = with DMARC.=C2=A0 If anyone wants to join me in looking at it through that = lens, you'd be welcome.

-MSK, co-chairin'<= br>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Seth Blank | Director, Indu= stry Initiatives
p:<= /span> 415.273.8818



This email and all data transmitted = with it contains confidential

= and/o= r proprietary information intended solely for the use of

individual(s) authorized= to receive it. If you are not an intended

and authorized = recipient you are hereby notified of any use,

disclosure, c= opying or distribution of the information included in

this transmission is prohib= ited and may be unlawful. Please

immediately notify the sen= der by replying to this email and then

delete it from your = system.

--000000000000b82045058c40a00b-- From nobody Thu Jun 27 02:10:45 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073EE12004A for ; Thu, 27 Jun 2019 02:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRQrsokuzX75 for ; Thu, 27 Jun 2019 02:10:41 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AFDD12000F for ; Thu, 27 Jun 2019 02:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1561626639; bh=VXcBC1dXd+ij3Blb9yO21YcF5Z3YciWdb5sUBYOlwuU=; l=7904; h=To:Cc:References:From:Date:In-Reply-To; b=BZ5Hwb5pf+CKEIViHs35jmkuKGZdI9iv00o+Y62vUzZHmenM0HHPdKvnozmbZHjAS twqoC9pdPwPoMEUmbhRytUUAFCaYo0H9QfazmuBR2vH23cF692+gK+StQ7ETNui0V7 74brDkq8Mlv6jTS1d5NRJZ287okfmOgRaJuDHeTrNCVUR7Zo5q63O4TjYLo8P Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 27 Jun 2019 11:10:39 +0200 id 00000000005DC043.000000005D14880F.00004D0B To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Thu, 27 Jun 2019 11:10:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-19723-1561626639-0001-2" In-Reply-To: Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 09:10:44 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-19723-1561626639-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Wed 26/Jun/2019 22:27:46 +0200 Murray S. Kucherawy wrote: > On Tue, Jun 4, 2019 at 4:01 AM Alessandro Vesely wrote: > >> Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF's >> reject-on-fail. The score attributed to the sender by a trusted DNSWL is >> also useful after DATA, thence the need to store that value for >> downstream filters.>> >> However, as an authentication method, a DNSWL TXT response can provide a >> domain name, which is possibly aligned with From:. In that sense, this >> method might be of interest for this WG. Probably not, but I felt >> compelled to make sure before trying independent submission. (Already >> tried ART.) The I-D is here:>> https://tools.ietf.org/html/draft-vesely-authmethod-dnswl >> > > With my Designated Expert hat on and co-chair hat off, a procedural point > here: > > The IANA registry for these is Expert Review, which means you don't have to > publish an RFC to get it registered. You can, but it's not necessary if > your registration request can sufficiently describe what you're doing. See > RFC8601 Section 6.2, fourth paragraph. I just submitted the form attached. This path seems to be quicker. Thanks. Let me paste the parameters, for list readers, and point out that dnswl can yield a domain name like, e.g., policy.txt=example.com. Whether the domain name alignment can be meaningful or not is the reason why this topic appears on this list. +--------+--------+----------+-------------------+--------+---------+ | Method | ptype | property | Value | Status | Version | +--------+--------+----------+-------------------+--------+---------+ | dnswl | dns | zone | DNSWL publicly | active | 1 | | | | | accessible query | | | | | | | root domain | | | | dnswl | policy | ip | type A response | active | 1 | | | | | received (or | | | | | | | comma-separated | | | | | | | list thereof) | | | | dnswl | policy | txt | type TXT query | active | 1 | | | | | response | | | +--------+--------+----------+-------------------+--------+---------+ Table 1: Email Authentication Method +-------+------------+----------------------------------------------+ | ptype | Definition | Description | +-------+------------+----------------------------------------------+ | dns | [this doc] | The property being reported belongs to the | | | | Domain Name System | +-------+------------+----------------------------------------------+ Table 2: Email Authentication Property Type +---------+-----------+------------------------------------+--------+ | Auth | Code | Specification | Status | | Method | | | | +---------+-----------+------------------------------------+--------+ | dnswl | pass | Sender is whitelisted, up to | active | | | | returned code interpretation | | | dnswl | none | NXDOMAIN or no record, sender is | active | | | | not whitelisted | | | dnswl | temperror | Transient DNS error during the | active | | | | query | | | dnswl | permerror | Query cannot work, human | active | | | | intervention needed | | +---------+-----------+------------------------------------+--------+ Best Ale -- --=_north-19723-1561626639-0001-2 Content-Type: message/rfc822; name="[IANA #1146140] AutoReply: Request for Assignment.eml" Content-Disposition: attachment; filename="[IANA #1146140] AutoReply: Request for Assignment.eml" X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on north.ext.tana.it X-Spam-Level: X-Spam-Status: No, score=0.2 required=9.0 tests=HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.2 Delivered-To: ale@tana.it Return-Path: Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=icann.org Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=HELO; sender=smtp01.icann.org; remoteip=192.0.33.81; remotehost=smtp01.icann.org; helo=smtp01.icann.org; receiver=wmail.tana.it; Received-SPF: pass (Address passes the Sender Policy Framework) SPF=MAILFROM; sender=iana-shared@icann.org; remoteip=192.0.33.81; remotehost=smtp01.icann.org; helo=smtp01.icann.org; receiver=wmail.tana.it; Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) by wmail.tana.it with ESMTPS; Thu, 27 Jun 2019 10:25:55 +0200 id 00000000005DC056.000000005D147D93.000046CF Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 091E8E3692 for ; Thu, 27 Jun 2019 07:54:19 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 04ABC2056A; Thu, 27 Jun 2019 07:54:19 +0000 (UTC) Subject: [IANA #1146140] AutoReply: Request for Assignment From: "IANA General Enquiries via RT" Reply-To: iana-questions@iana.org In-Reply-To: <2tcqyug0n2-1@ppa4.dc.icann.org> References: <2tcqyug0n2-1@ppa4.dc.icann.org> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1146140 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: vesely@tana.it Auto-Submitted: auto-replied To: vesely@tana.it X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 27 Jun 2019 07:54:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Received-SPF: pass (Address passes the Sender Policy Framework) SPF=FROM; sender=iana-questions@iana.org; remoteip=192.0.33.81; remotehost=smtp01.icann.org; helo=smtp01.icann.org; receiver=wmail.tana.it; X-Mime-Autoconverted: from 8bit to 7bit by courier 0.76 To whom it may concern: This is an automatically generated message to notify you that we have received your request, and it has been recorded in our ticketing system with a reference number of 1146140. There is no need to reply to this message right now. IANA staff will review your message and reply to your inquiry within three (3) business days. If this message is in reply to a previously submitted ticket, it is possible that the previous ticket has been marked as closed. As we review this ticket, we will also review previous correspondence and take appropriate action. To expedite processing, and ensure our staff can view the full history of this request, please make sure you include the follow exact text in the subject line of all future correspondence on this issue: [IANA #1146140] You can also simply reply to this message, as this tag is already in the subject line. Thank you, IANA Services iana-questions@iana.org PTI Please note: By submitting my personal data, I agree that my personal data will be processed in accordance with the Privacy Policy . ------------------------------------------------------------------------- Contact Name: Alessandro Vesely Contact Email: vesely@tana.it Type of Assignment: Protocol Registries, Email Authentication Parameters Registry: Email Authentication Method, Property Type, and Result Names Description: The method is being used by the Courier-MTA mail server. Registration helps documentation and avoids confusion in case the same names are used for different functions. Additional Info: https://tools.ietf.org/html/draft-vesely-authmethod-dnswl-08#section-4 (three tables of respectively three, one, and four entries.) --=_north-19723-1561626639-0001-2-- From nobody Thu Jun 27 03:52:24 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF82120234 for ; Thu, 27 Jun 2019 03:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=AwJpdlCc; dkim=pass (1536-bit key) header.d=taugh.com header.b=W1xNsGry 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 d_nmuZ3Akx9u for ; Thu, 27 Jun 2019 03:52:21 -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 5EE91120137 for ; Thu, 27 Jun 2019 03:52:21 -0700 (PDT) Received: (qmail 94464 invoked from network); 27 Jun 2019 10:52: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:mime-version:content-type:content-transfer-encoding; s=170fd.5d149fe3.k1906; i=johnl-iecc.com@submit.iecc.com; bh=au+FHp/c38eh9YjI4vKmIyRiVXbMuP09Z8uVCOlOb9E=; b=AwJpdlCcrAiVUPq29z6Y2GzcSoklWkbzvxwb8a8UqZk+ze1o4oQIiYiB2/PNHd0Vv6XJphbqTHhfON0PcQ9xJgO9jrZxqSUwuXzetv10Cnq3O5GuS68bTBP9WdWEU+b8ftTiW52Co9F8L6ISmneWDH5z0sj14hoYCgTiPqTUAeOSWoZ3pS5RBMuNtN+33AMGsTevSTn02Ljv+svXPyK51J3wslg34rlyHSgePGDj5FLWBk0Ytk1w9SHToVGaFm0y 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=170fd.5d149fe3.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=au+FHp/c38eh9YjI4vKmIyRiVXbMuP09Z8uVCOlOb9E=; b=W1xNsGryIqlYgflfxqRjxyKZj9j+HTeHZ6DgByzGWrGmyrrqv7zK9VhVcXSfpcoeIsZK32gcfRPG8YfayBUnpEbBqRxff2EDTJOpzp1WllJs5FcFQVjPEsNRXB5YnrEDpjlD9pur01I3BhBkRua9dyiQ50aBdT+KtndFVz7UBlO9p6n8qm+3IFJGOuwZBonujk6640K6raQHGLq8DvQ7pPWEbpBSH4cMfheDxtbRo6I4QiejLin6yHKb1fHQ23Sp Received: from ary.local ([199.91.196.51]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 27 Jun 2019 10:52:19 -0000 Received: by ary.local (Postfix, from userid 501) id 48BA5201676392; Thu, 27 Jun 2019 11:52:16 +0100 (+01) Date: 27 Jun 2019 11:52:16 +0100 Message-Id: <20190627105217.48BA5201676392@ary.local> 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] PSDs in 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, 27 Jun 2019 10:52:23 -0000 >I concur. Does anyone know of such a policy statement from ICANN? I don't >recall it being present in, say, any of the DNS RFCs, but there are so many >of those now... Hi from ICANN 65 in Marrakech. The gTLD registry contracts say directly or indirectly what's allowed in each TLD zone. Here's the language in the base registry agreement that the new TLDs all use: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1 For the older TLDs, notably .com, the contract refers to Consensus Policies, which are at https://www.icann.org/resources/pages/registrars/consensus-policies-en One of those policies is the Registry Services Evaluation Policy (RSEP) which is at https://www.icann.org/resources/pages/registries/rsep/policy-en Here's the list of RSEP requests: https://www.icann.org/resources/pages/rsep-2014-02-19-en Adding a dmarc record to individual TLD would need an RSEP, for which an RFC would likely be helpful but probably not essential. The RSEP process for things that are not politically controversial is not particularly hard. Adding them to all of the TLDs could be a new consensus policy, or maybe a change to the base agreement. How to do that is above my pay grade. R's, John From nobody Thu Jun 27 04:23:46 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E300120043 for ; Thu, 27 Jun 2019 04:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=verisign.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 EXQI9I72HF03 for ; Thu, 27 Jun 2019 04:23:42 -0700 (PDT) Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 310681200B8 for ; Thu, 27 Jun 2019 04:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2184; q=dns/txt; s=VRSN; t=1561634622; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=fFmMcMQk7ihrbVoU6aD+vt4AB3q3H3VZCDBVm3rmngo=; b=Cc0BZksIn7d2AGRI/WBkHJW3jiORrZkiidwnBmwNAt91hllN0BzRBOX1 ASH+XA7VqT0WZ9E/z2w39pDXL29gXyWMXb0G8ce6V1RoXYeQMAxDNrtDg /vNBdHekY7Kms6YNZ0MMOnX69c6lJAYVtPqM3SFlkXC4rNrZUO6h7OkQ5 cvUQNGTFg0YdG6go1K/qd2ZrIEs6SWr5BxzdV38FuKCvDIeGp2w8BUZNo 4R2H32U+PQNtaFfksaT0/XKtDUPdbN/G66SqnqnvTJN4BSd9Zm5h7X4ah fhah7E9A0tiZy2t1zZnUKkRAekMLYaJcPA0Mv64hWpz9utf7RvNpxQNxe A==; X-IronPort-AV: E=Sophos;i="5.63,423,1557201600"; d="scan'208";a="7861459" IronPort-PHdr: =?us-ascii?q?9a23=3A6pW8PBFEgylFcJqxAo9qZZ1GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ76p8W+bnLW6fgltlLVR4KTs6sC17OM9fmwEjdQqdbZ6TZeKcUKD0?= =?us-ascii?q?dEwewt3CUYSPafDkP6KPO4JwcbJ+9lEGFfwnegLEJOE9z/bVCB6le77DoVBw?= =?us-ascii?q?mtfVEtfre9FYHdldm42P6v8JPPfQpImCC9YbRvJxmqsAndrMYbjZZ8Jqor1x?= =?us-ascii?q?fEoXREdupVyGh1IV6fgwvw6t2/8ZJ+7ihcoe4t+9JFXa7nY6k2ULtUASg8PW?= =?us-ascii?q?so/sPrrx7DTQWO5nsYTGoblwdDDhbG4h/nQJr/qzP2ueVh1iaUO832Vq00Vi?= =?us-ascii?q?+576h3Uh/oiTwIOCA//WrKl8F/lqNboBampxxi347ZZZyeOfRicq/Be94RWG?= =?us-ascii?q?xMVdtTWSNcGIOxd4sBAfQcM+ZEoYfzpFUOohm/BQawC+3gxSRFhmPv3a04z+?= =?us-ascii?q?gtDR3K0BImEtkTsHrUttL1NKIKXOy7zqfIyjHDb/dI1jf784fHbAwuofKUUb?= =?us-ascii?q?ltbMTe1U4vFx/ZjlmetIfoOCiV1uQKs2if6+pvS+SvhHU5pA5toTii3dkshZ?= =?us-ascii?q?fThoIU0VDE9Cp5wIAvKdKkT057ZMepHZ1NvC+UMIt2R9ktQ2BuuCsizL0Gvo?= =?us-ascii?q?K7czIRx5Qjxx/TceCIc4+N4h77VeaePS13hHRjeL6lgBay60egx+vhXce3yF?= =?us-ascii?q?ZHtjdJnsXWunwQ1RHe5NKLRuZ980qvwzqC2APe5vlZLUwoj6bXNpwszqIqmp?= =?us-ascii?q?YOvknOHTX6lFj1gaOOeEUr5Oul5/jib7jjpJKTK5N4hRv7P6gzhsOwHeE1Pw?= =?us-ascii?q?gTUGeF9+Sx0bnu8lDkT7pUiPA9j7PXv4rAJcsBo660GwpV0oE+5BmhFzqmy9?= =?us-ascii?q?EYnWUfLFJCZRKHk5DlO1HQL/D8Cveym0mhnitzyfzbPrLvGprDIXnfnLv8Z7?= =?us-ascii?q?p99VJTyA0pzdBH/Z5bEKwOLOjtWk/rr9zYCAU1PBCzw+biENl914UeVnyTAq?= =?us-ascii?q?KBLa/erUWE6v8tLuSCfoMZpTbwJvY/6/PhjnI1gVodcrOo3ZsTZnC4BPNmI0?= =?us-ascii?q?CBbHr3gtcBFmMKvg4gQ+zsk1KNTyJcZ3WpUqIi+D47EoOmDZzCRoCihryNxj?= =?us-ascii?q?u0HppTZmxeEFCDDW/od5mYW/cLcC+SIMhhkjwCVbilUIIhyQuhtBL1y7pnNO?= =?us-ascii?q?bb5ioYtZf73thv++LTjQ0y9SBzD8mFzm6NSnt7nnkUSDIt3aBwv1B9ylmZ3a?= =?us-ascii?q?h/mfxYGsRZ5+lVXQciKZ7c0+t6BsjpWgLcZteGVkymQsi9AT4vVNI82NAOY0?= =?us-ascii?q?NnFNWjihDPxTalA7gQl+/DOJthuKDb3371D9p01nnGkqImihNuFslINWuirr?= =?us-ascii?q?J26gfTQYXOlhPd3+ymcK0G1wbM+XuNi22UswsQBAJ1WL/OdXESekWQqs72sB?= =?us-ascii?q?DsVbirXP4HNQ9FxMiIJ6BJLpXShlJaWL2rbM/eZGa1lmG6CB2L7q2Bdovxem?= =?us-ascii?q?obmi7aDR5XwEgo4X+aOF1mVW+aqGXEAWk2GA=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2EJAACVphRd/zCZrQpkGgEBAQEBAgEBAQEHAgEBAQGBV?= =?us-ascii?q?QMBAQEBCwGDAIEsCpkQiUuPIoF7CQEBAQEBAQEBAQcBIwwBAQKEPgKDIzYHD?= =?us-ascii?q?gEDAQEBBAEBAQEEAQEBAosgDII6IhxNawEBAQEBASMCDWMBAQEBAzo/DAQCA?= =?us-ascii?q?QgRBAEBHxAhER0IAgQBDQUIgxuBagMspxeENgMLAQI7BAFAgkENgh8GgTQBi?= =?us-ascii?q?3WBQT6BEYMSPoIaRwGHRASMOp0tPwMGAoIXhlKJMoNpI4IrhxeOHI0phziBc?= =?us-ascii?q?I12AgQCBAUCFYFXAoIIcFCCbIJNF4hihT9yjguBIQEB?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 27 Jun 2019 07:23:40 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Thu, 27 Jun 2019 07:23:40 -0400 From: "Hollenbeck, Scott" To: "johnl@taugh.com" , "dmarc@ietf.org" CC: "superuser@gmail.com" Thread-Topic: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd Thread-Index: AQHVLGCulBQe5GmoB0y7GawpTRvjMaavlxEA///CkIA= Date: Thu, 27 Jun 2019 11:23:40 +0000 Message-ID: <0d4e70733ed0472eb80fd5150f4b5534@verisign.com> References: <20190627105217.48BA5201676392@ary.local> In-Reply-To: <20190627105217.48BA5201676392@ary.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 27 Jun 2019 11:23:45 -0000 > -----Original Message----- > From: dmarc On Behalf Of John Levine > Sent: Thursday, June 27, 2019 6:52 AM > To: dmarc@ietf.org > Cc: superuser@gmail.com > Subject: [EXTERNAL] Re: [dmarc-ietf] PSDs in draft-ietf-dmarc-psd > > >I concur. Does anyone know of such a policy statement from ICANN? I > >don't recall it being present in, say, any of the DNS RFCs, but there > >are so many of those now... > > Hi from ICANN 65 in Marrakech. > > The gTLD registry contracts say directly or indirectly what's allowed in = each > TLD zone. Here's the language in the base registry agreement that the ne= w > TLDs all use: > > https://newgtlds.icann.org/sites/default/files/agreements/agreement- > approved-31jul17-en.html#exhibitA.1 > > For the older TLDs, notably .com, the contract refers to Consensus Polici= es, > which are at https://www.icann.org/resources/pages/registrars/consensus- > policies-en > > One of those policies is the Registry Services Evaluation Policy > (RSEP) which is at > https://www.icann.org/resources/pages/registries/rsep/policy-en > > Here's the list of RSEP requests: > > https://www.icann.org/resources/pages/rsep-2014-02-19-en > > Adding a dmarc record to individual TLD would need an RSEP, for which an > RFC would likely be helpful but probably not essential. The RSEP process= for > things that are not politically controversial is not particularly hard. > > Adding them to all of the TLDs could be a new consensus policy, or maybe = a > change to the base agreement. How to do that is above my pay grade. The ICANN minutiae is probably way more detail than is needed in the docume= nt. I'd be more comfortable if there were text in the Introduction along th= e lines of what Murray said in his last note (paraphrased here slightly): "= Please note that today's operational and policy reality prevents this exper= iment from being deployed globally. If the experiment shows that PSD solve= s a real problem at a large scale, the results could prove to be useful in = the development of policies outside of the IETF that would permit its ubiqu= itous deployment". Scott From nobody Thu Jun 27 08:56:44 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC931202B5 for ; Thu, 27 Jun 2019 08:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1536-bit key) header.d=iecc.com header.b=VjfLn4ng; dkim=pass (1536-bit key) header.d=taugh.com header.b=LEzAi/CA 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 OROIV4OLXqdb for ; Thu, 27 Jun 2019 08:56:40 -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 A8E451202B1 for ; Thu, 27 Jun 2019 08:56:39 -0700 (PDT) Received: (qmail 72682 invoked from network); 27 Jun 2019 15:56:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=11be7.5d14e735.k1906; i=johnl-iecc.com@submit.iecc.com; bh=EOAfuG+CINm9MOtNgc/AeB4TWkDB4k98ivcv3KWBd3w=; b=VjfLn4ngoBimLfPJJufJImwjhoWxohXhatXntSwikyb4aOcbyXwwfp9Oh0rJUJnKnlALKSaRTaajtbP4op36yi3eBWaGX7dMNUJTP8q1EuLR2o+bp2P3ADaQFTRW0Wb8pqjfx9PxaMDrHNDvRFl9rCSvDxyCFDa+h7MOTTbP+oU6We8TXImWnHehIJoGa0B7O+slcQesQi/wW3RzBTDhx+8sRbIMDxhUX11Q6w9xuOoCDNR7DFPCFn+4qVl/q/Vp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=11be7.5d14e735.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=EOAfuG+CINm9MOtNgc/AeB4TWkDB4k98ivcv3KWBd3w=; b=LEzAi/CAfk8SAu0rXYiHRTEhTMYvMpZwc+ci2zZPEwow2EcI1CzH30IndkrtVYwSU0im8+it8Q/Kt7ilBDlHydD5tqvBvoZZQaKl0yUHWw1g304e0VKRSN4dRnDBCT92QJc2/KYFetsitQ2f87LkuEz+TrLZk+8p0tobqbJgFvuWwWdRcVaG84bX/CzaBqXUfCldXmfTi9j1i5GGn0AlbZ+NQlVygZGSqLZSieOrtm9seAYThvtzkiBZM/tDpXr1 Received: from 105.67.133.47 ([105.67.133.47]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-128-GCM AEAD, johnl@iecc.com) via TCP; 27 Jun 2019 15:56:36 -0000 Date: 27 Jun 2019 16:56:28 +0100 Message-ID: <20190627165628.72678.qmail@submit.iecc.com> From: "John Levine" To: shollenbeck@verisign.com Cc: dmarc@ietf.org, "Murray S. Kucherawy" Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 27 Jun 2019 15:56:43 -0000 SSB3YXNuJ3QgdGhpbmtpbmcgdGhpcyB3b3VsZCBnbyBpbiB0aGUgZG9jLCBqdXN0IGZvciBiYWNr Z3JvdW5kLgoKQXV0b2NvcnJlY3RseSwKSm9obgpPbiAyNyBKdW4gMjAxOSAxMjoyMywgIkhvbGxl bmJlY2ssIFNjb3R0IiA8c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPiB3cm90ZToKPgo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gCj4gPiBGcm9tOiBkbWFyYyA8ZG1hcmMtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gTGV2aW5lIAo+ID4gU2VudDogVGh1cnNkYXksIEp1 bmUgMjcsIDIwMTkgNjo1MiBBTSAKPiA+IFRvOiBkbWFyY0BpZXRmLm9yZyAKPiA+IENjOiBzdXBl cnVzZXJAZ21haWwuY29tIAo+ID4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW2RtYXJjLWlldGZd IFBTRHMgaW4gZHJhZnQtaWV0Zi1kbWFyYy1wc2QgCj4gPiAKPiA+ID5JIGNvbmN1ci7CoCBEb2Vz IGFueW9uZSBrbm93IG9mIHN1Y2ggYSBwb2xpY3kgc3RhdGVtZW50IGZyb20gSUNBTk4/wqAgSSAK PiA+ID5kb24ndCByZWNhbGwgaXQgYmVpbmcgcHJlc2VudCBpbiwgc2F5LCBhbnkgb2YgdGhlIERO UyBSRkNzLCBidXQgdGhlcmUgCj4gPiA+YXJlIHNvIG1hbnkgb2YgdGhvc2Ugbm93Li4uIAo+ID4g Cj4gPiBIaSBmcm9tIElDQU5OIDY1IGluIE1hcnJha2VjaC4gCj4gPiAKPiA+IFRoZSBnVExEIHJl Z2lzdHJ5IGNvbnRyYWN0cyBzYXkgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB3aGF0J3MgYWxsb3dl ZCBpbiBlYWNoIAo+ID4gVExEIHpvbmUuwqAgSGVyZSdzIHRoZSBsYW5ndWFnZSBpbiB0aGUgYmFz ZSByZWdpc3RyeSBhZ3JlZW1lbnQgdGhhdCB0aGUgbmV3IAo+ID4gVExEcyBhbGwgdXNlOiAKPiA+ IAo+ID4gaHR0cHM6Ly9uZXdndGxkcy5pY2Fubi5vcmcvc2l0ZXMvZGVmYXVsdC9maWxlcy9hZ3Jl ZW1lbnRzL2FncmVlbWVudC0gCj4gPiBhcHByb3ZlZC0zMWp1bDE3LWVuLmh0bWwjZXhoaWJpdEEu MSAKPiA+IAo+ID4gRm9yIHRoZSBvbGRlciBUTERzLCBub3RhYmx5IC5jb20sIHRoZSBjb250cmFj dCByZWZlcnMgdG8gQ29uc2Vuc3VzIFBvbGljaWVzLCAKPiA+IHdoaWNoIGFyZSBhdCBodHRwczov L3d3dy5pY2Fubi5vcmcvcmVzb3VyY2VzL3BhZ2VzL3JlZ2lzdHJhcnMvY29uc2Vuc3VzLSAKPiA+ IHBvbGljaWVzLWVuIAo+ID4gCj4gPiBPbmUgb2YgdGhvc2UgcG9saWNpZXMgaXMgdGhlIFJlZ2lz dHJ5IFNlcnZpY2VzIEV2YWx1YXRpb24gUG9saWN5IAo+ID4gKFJTRVApIHdoaWNoIGlzIGF0IAo+ ID4gaHR0cHM6Ly93d3cuaWNhbm4ub3JnL3Jlc291cmNlcy9wYWdlcy9yZWdpc3RyaWVzL3JzZXAv cG9saWN5LWVuIAo+ID4gCj4gPiBIZXJlJ3MgdGhlIGxpc3Qgb2YgUlNFUCByZXF1ZXN0czogCj4g PiAKPiA+IGh0dHBzOi8vd3d3LmljYW5uLm9yZy9yZXNvdXJjZXMvcGFnZXMvcnNlcC0yMDE0LTAy LTE5LWVuIAo+ID4gCj4gPiBBZGRpbmcgYSBkbWFyYyByZWNvcmQgdG8gaW5kaXZpZHVhbCBUTEQg d291bGQgbmVlZCBhbiBSU0VQLCBmb3Igd2hpY2ggYW4gCj4gPiBSRkMgd291bGQgbGlrZWx5IGJl IGhlbHBmdWwgYnV0IHByb2JhYmx5IG5vdCBlc3NlbnRpYWwuwqAgVGhlIFJTRVAgcHJvY2VzcyBm b3IgCj4gPiB0aGluZ3MgdGhhdCBhcmUgbm90IHBvbGl0aWNhbGx5IGNvbnRyb3ZlcnNpYWwgaXMg bm90IHBhcnRpY3VsYXJseSBoYXJkLiAKPiA+IAo+ID4gQWRkaW5nIHRoZW0gdG8gYWxsIG9mIHRo ZSBUTERzIGNvdWxkIGJlIGEgbmV3IGNvbnNlbnN1cyBwb2xpY3ksIG9yIG1heWJlIGEgCj4gPiBj aGFuZ2UgdG8gdGhlIGJhc2UgYWdyZWVtZW50LsKgIEhvdyB0byBkbyB0aGF0IGlzIGFib3ZlIG15 IHBheSBncmFkZS4gCj4KPiBUaGUgSUNBTk4gbWludXRpYWUgaXMgcHJvYmFibHkgd2F5IG1vcmUg ZGV0YWlsIHRoYW4gaXMgbmVlZGVkIGluIHRoZSBkb2N1bWVudC4gSSdkIGJlIG1vcmUgY29tZm9y dGFibGUgaWYgdGhlcmUgd2VyZSB0ZXh0IGluIHRoZSBJbnRyb2R1Y3Rpb24gYWxvbmcgdGhlIGxp bmVzIG9mIHdoYXQgTXVycmF5IHNhaWQgaW4gaGlzIGxhc3Qgbm90ZSAocGFyYXBocmFzZWQgaGVy ZSBzbGlnaHRseSk6ICJQbGVhc2Ugbm90ZSB0aGF0IHRvZGF5J3Mgb3BlcmF0aW9uYWwgYW5kIHBv bGljeSByZWFsaXR5IHByZXZlbnRzIHRoaXMgZXhwZXJpbWVudCBmcm9tIGJlaW5nIGRlcGxveWVk IGdsb2JhbGx5LsKgIElmIHRoZSBleHBlcmltZW50IHNob3dzIHRoYXQgUFNEIHNvbHZlcyBhIHJl YWwgcHJvYmxlbSBhdCBhIGxhcmdlIHNjYWxlLCB0aGUgcmVzdWx0cyBjb3VsZCBwcm92ZSB0byBi ZSB1c2VmdWwgaW4gdGhlIGRldmVsb3BtZW50IG9mIHBvbGljaWVzIG91dHNpZGUgb2YgdGhlIElF VEYgdGhhdCB3b3VsZCBwZXJtaXQgaXRzIHViaXF1aXRvdXMgZGVwbG95bWVudCIuIAo+Cj4gU2Nv dHQgCj4K From nobody Thu Jun 27 08:56:52 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5403120296 for ; Thu, 27 Jun 2019 08:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Af+7a6XK; dkim=pass (1536-bit key) header.d=taugh.com header.b=fD9ueO/C 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 4b0bQ2Sl-E-c for ; Thu, 27 Jun 2019 08:56:40 -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 A8DC91202A4 for ; Thu, 27 Jun 2019 08:56:39 -0700 (PDT) Received: (qmail 72690 invoked from network); 27 Jun 2019 15:56:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=11bef.5d14e736.k1906; i=johnl-iecc.com@submit.iecc.com; bh=EOAfuG+CINm9MOtNgc/AeB4TWkDB4k98ivcv3KWBd3w=; b=Af+7a6XKX4LnxHiv/dFEh3ZYxpfs33fclu1grukvmDmbkvzLS//JLR57lVWiubIVqX4MaA+qR4bNg3nkSpyUXe9pSazrHrdIuuzSLbWrAAcsTeWnedIu6jCIxDI1to/7FhtlzgKhWdl2BHYxF3BsLeILFvbspDhPh0FsVg4aSp8t93wCycrNVmwvNmArt8K3R9ecNaJ6VtTFAD/DhwQ9AdoJNo4A/G9lpOAG7NJSU/vyfzx1THWlE9Abzq74lLjK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:content-transfer-encoding; s=11bef.5d14e736.k1906; olt=johnl-iecc.com@submit.iecc.com; bh=EOAfuG+CINm9MOtNgc/AeB4TWkDB4k98ivcv3KWBd3w=; b=fD9ueO/CQIeiHH/E3QHPdLZ2nl7om7Q7fmG/yJmNwiO9HeTerklSHIrMT926lAjLobPoFN+kLOvzhS6c17NFWcEtDg3L9PPW7uNd3SdOjynJ0lrxZ9iqmt4vCCDQNaRLWELMrmnF+ANx8N+cBlbAWd+hNL5RPMn7R+vXMc0xmw23Hn/YDkeeG+vpDV95Xl6lPqPRN5Xlf0FIrNzPruji0z4FxwrBr5+bEC8s0sKMry3MMMWEBUei/ZCh23+6gUZU Received: from 105.67.133.47 ([105.67.133.47]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-128-GCM AEAD, johnl@iecc.com) via TCP; 27 Jun 2019 15:56:37 -0000 Date: 27 Jun 2019 16:56:28 +0100 Message-ID: <20190627165628.72686.qmail@submit.iecc.com> From: "John Levine" To: shollenbeck@verisign.com Cc: dmarc@ietf.org, "Murray S. Kucherawy" Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dmarc-ietf] PSDs in 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, 27 Jun 2019 15:56:44 -0000 SSB3YXNuJ3QgdGhpbmtpbmcgdGhpcyB3b3VsZCBnbyBpbiB0aGUgZG9jLCBqdXN0IGZvciBiYWNr Z3JvdW5kLgoKQXV0b2NvcnJlY3RseSwKSm9obgpPbiAyNyBKdW4gMjAxOSAxMjoyMywgIkhvbGxl bmJlY2ssIFNjb3R0IiA8c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPiB3cm90ZToKPgo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gCj4gPiBGcm9tOiBkbWFyYyA8ZG1hcmMtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gTGV2aW5lIAo+ID4gU2VudDogVGh1cnNkYXksIEp1 bmUgMjcsIDIwMTkgNjo1MiBBTSAKPiA+IFRvOiBkbWFyY0BpZXRmLm9yZyAKPiA+IENjOiBzdXBl cnVzZXJAZ21haWwuY29tIAo+ID4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW2RtYXJjLWlldGZd IFBTRHMgaW4gZHJhZnQtaWV0Zi1kbWFyYy1wc2QgCj4gPiAKPiA+ID5JIGNvbmN1ci7CoCBEb2Vz IGFueW9uZSBrbm93IG9mIHN1Y2ggYSBwb2xpY3kgc3RhdGVtZW50IGZyb20gSUNBTk4/wqAgSSAK PiA+ID5kb24ndCByZWNhbGwgaXQgYmVpbmcgcHJlc2VudCBpbiwgc2F5LCBhbnkgb2YgdGhlIERO UyBSRkNzLCBidXQgdGhlcmUgCj4gPiA+YXJlIHNvIG1hbnkgb2YgdGhvc2Ugbm93Li4uIAo+ID4g Cj4gPiBIaSBmcm9tIElDQU5OIDY1IGluIE1hcnJha2VjaC4gCj4gPiAKPiA+IFRoZSBnVExEIHJl Z2lzdHJ5IGNvbnRyYWN0cyBzYXkgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB3aGF0J3MgYWxsb3dl ZCBpbiBlYWNoIAo+ID4gVExEIHpvbmUuwqAgSGVyZSdzIHRoZSBsYW5ndWFnZSBpbiB0aGUgYmFz ZSByZWdpc3RyeSBhZ3JlZW1lbnQgdGhhdCB0aGUgbmV3IAo+ID4gVExEcyBhbGwgdXNlOiAKPiA+ IAo+ID4gaHR0cHM6Ly9uZXdndGxkcy5pY2Fubi5vcmcvc2l0ZXMvZGVmYXVsdC9maWxlcy9hZ3Jl ZW1lbnRzL2FncmVlbWVudC0gCj4gPiBhcHByb3ZlZC0zMWp1bDE3LWVuLmh0bWwjZXhoaWJpdEEu MSAKPiA+IAo+ID4gRm9yIHRoZSBvbGRlciBUTERzLCBub3RhYmx5IC5jb20sIHRoZSBjb250cmFj dCByZWZlcnMgdG8gQ29uc2Vuc3VzIFBvbGljaWVzLCAKPiA+IHdoaWNoIGFyZSBhdCBodHRwczov L3d3dy5pY2Fubi5vcmcvcmVzb3VyY2VzL3BhZ2VzL3JlZ2lzdHJhcnMvY29uc2Vuc3VzLSAKPiA+ IHBvbGljaWVzLWVuIAo+ID4gCj4gPiBPbmUgb2YgdGhvc2UgcG9saWNpZXMgaXMgdGhlIFJlZ2lz dHJ5IFNlcnZpY2VzIEV2YWx1YXRpb24gUG9saWN5IAo+ID4gKFJTRVApIHdoaWNoIGlzIGF0IAo+ ID4gaHR0cHM6Ly93d3cuaWNhbm4ub3JnL3Jlc291cmNlcy9wYWdlcy9yZWdpc3RyaWVzL3JzZXAv cG9saWN5LWVuIAo+ID4gCj4gPiBIZXJlJ3MgdGhlIGxpc3Qgb2YgUlNFUCByZXF1ZXN0czogCj4g PiAKPiA+IGh0dHBzOi8vd3d3LmljYW5uLm9yZy9yZXNvdXJjZXMvcGFnZXMvcnNlcC0yMDE0LTAy LTE5LWVuIAo+ID4gCj4gPiBBZGRpbmcgYSBkbWFyYyByZWNvcmQgdG8gaW5kaXZpZHVhbCBUTEQg d291bGQgbmVlZCBhbiBSU0VQLCBmb3Igd2hpY2ggYW4gCj4gPiBSRkMgd291bGQgbGlrZWx5IGJl IGhlbHBmdWwgYnV0IHByb2JhYmx5IG5vdCBlc3NlbnRpYWwuwqAgVGhlIFJTRVAgcHJvY2VzcyBm b3IgCj4gPiB0aGluZ3MgdGhhdCBhcmUgbm90IHBvbGl0aWNhbGx5IGNvbnRyb3ZlcnNpYWwgaXMg bm90IHBhcnRpY3VsYXJseSBoYXJkLiAKPiA+IAo+ID4gQWRkaW5nIHRoZW0gdG8gYWxsIG9mIHRo ZSBUTERzIGNvdWxkIGJlIGEgbmV3IGNvbnNlbnN1cyBwb2xpY3ksIG9yIG1heWJlIGEgCj4gPiBj aGFuZ2UgdG8gdGhlIGJhc2UgYWdyZWVtZW50LsKgIEhvdyB0byBkbyB0aGF0IGlzIGFib3ZlIG15 IHBheSBncmFkZS4gCj4KPiBUaGUgSUNBTk4gbWludXRpYWUgaXMgcHJvYmFibHkgd2F5IG1vcmUg ZGV0YWlsIHRoYW4gaXMgbmVlZGVkIGluIHRoZSBkb2N1bWVudC4gSSdkIGJlIG1vcmUgY29tZm9y dGFibGUgaWYgdGhlcmUgd2VyZSB0ZXh0IGluIHRoZSBJbnRyb2R1Y3Rpb24gYWxvbmcgdGhlIGxp bmVzIG9mIHdoYXQgTXVycmF5IHNhaWQgaW4gaGlzIGxhc3Qgbm90ZSAocGFyYXBocmFzZWQgaGVy ZSBzbGlnaHRseSk6ICJQbGVhc2Ugbm90ZSB0aGF0IHRvZGF5J3Mgb3BlcmF0aW9uYWwgYW5kIHBv bGljeSByZWFsaXR5IHByZXZlbnRzIHRoaXMgZXhwZXJpbWVudCBmcm9tIGJlaW5nIGRlcGxveWVk IGdsb2JhbGx5LsKgIElmIHRoZSBleHBlcmltZW50IHNob3dzIHRoYXQgUFNEIHNvbHZlcyBhIHJl YWwgcHJvYmxlbSBhdCBhIGxhcmdlIHNjYWxlLCB0aGUgcmVzdWx0cyBjb3VsZCBwcm92ZSB0byBi ZSB1c2VmdWwgaW4gdGhlIGRldmVsb3BtZW50IG9mIHBvbGljaWVzIG91dHNpZGUgb2YgdGhlIElF VEYgdGhhdCB3b3VsZCBwZXJtaXQgaXRzIHViaXF1aXRvdXMgZGVwbG95bWVudCIuIAo+Cj4gU2Nv dHQgCj4K From nobody Sun Jun 30 18:20:55 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CF61201E3; Sun, 30 Jun 2019 18:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qhp8Z62ggxK; Sun, 30 Jun 2019 18:20:50 -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 135871201E8; Sun, 30 Jun 2019 18:20:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C9311B81C50; Sun, 30 Jun 2019 18:20:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dmarc@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190701012043.C9311B81C50@rfc-editor.org> Date: Sun, 30 Jun 2019 18:20:43 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] =?utf-8?q?RFC_8616_on_Email_Authentication_for_Inte?= =?utf-8?q?rnationalized_Mail?= 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, 01 Jul 2019 01:20:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8616 Title: Email Authentication for Internationalized Mail Author: J. Levine Status: Standards Track Stream: IETF Date: June 2019 Mailbox: standards@taugh.com Pages: 6 Characters: 14338 Updates: RFC 6376, RFC 7208, RFC 7489 I-D Tag: draft-ietf-dmarc-eaiauth-06.txt URL: https://www.rfc-editor.org/info/rfc8616 DOI: 10.17487/RFC8616 Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications. This document is a product of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC