From nobody Thu Aug 1 00:05: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 04110120025 for ; Thu, 1 Aug 2019 00:05:16 -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 dXnJ-XyApzCS for ; Thu, 1 Aug 2019 00:05:14 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66E9120141 for ; Thu, 1 Aug 2019 00:05:13 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id p197so49369317lfa.2 for ; Thu, 01 Aug 2019 00:05:13 -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=hZ5JsWvs8sL7p8FxOtV7C+jqh1eJU4bm9L1VDDl8y6E=; b=X7/NisnWLDC0vOHSskQ0kaD3XcS0M8RD1JP+/bLQTaCixqsR/2r30JfN282uBrPuIY acugfe10tIQg9e7MCFc3NwZO5hLhk0OVg9vb1bBnXSOtGiGpYEYISd874Ng9A4alcBvI uCGWVKZ9rVzsBgHy2/RghkBbe2zN+KZWLPrWkfLIVd/5D8n4jGIPnmlUiMdWNKBfYxG7 WeOnplC3ci0sbQ9AwkFZGXl6cIUZHj4KGK3VXXnmmwrFPmh+orubjmPYWY/SQ+2ZQmgb NdnTbs4Jqi3INtv5xRvpdwcVU1RY3YWJbcXc8R03idPvHlCW86Om5e5my9yLywWtvTRW Rnzg== 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=hZ5JsWvs8sL7p8FxOtV7C+jqh1eJU4bm9L1VDDl8y6E=; b=L+fGUwyTNHtFuncclZM4Hz/yfg2wnqns0Wk16sFChHxoqprEmrc1ALUsQNh1TITKQO mb/3/CPu5TKtrOaUhlco8+PmI4QSNR06ZxwafSZKw2GrMUVlwCYShnMiV3Q+a6dfvlbs Thp2TLSxUW7rt3mIxyRaeP/t13NGAi0isZBALFxxGruN5ERa+FQsCXIJZEBOgn49W8Rp TZs9EkfLM/XsRUh7khUShTjXjqDTGPPsH89+iOQg1taxcSRbY7AwUAlkvZO6LVg6i/7N OPY+wOycPCUaA0UxjOGlXMBFlOkHvHoatNukL+/USlshMDPlQOP6PyqWIV3ITgCWsVKl B4Vg== X-Gm-Message-State: APjAAAU9dQyrw6hTISOPBuFLQ5kl6kIBRln0Y+uuJ0ukzVdR4WQDMjx1 dFh3BPVJU2522Mabc7yHbGBzzXcbrPhBXghFL0A= X-Google-Smtp-Source: APXvYqyo5mm0Y4vxgjMzRmwqF2QEzs6cONwEhy8FAeDpOmXbKGz+wSZDunfUYeXC2wRR0m/U43ohJrewSheRDKXmJiU= X-Received: by 2002:a19:6e4d:: with SMTP id q13mr18792001lfk.6.1564643111954; Thu, 01 Aug 2019 00:05:11 -0700 (PDT) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 1 Aug 2019 00:04:59 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e36d9b058f08dcc1" 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, 01 Aug 2019 07:05:16 -0000 --000000000000e36d9b058f08dcc1 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 31, 2019 at 10:27 PM Murray S. Kucherawy wrote: > > Appendix C of RFC8601 goes to some length to discourage the practice of > including all the details that were inputs to the evaluation, specifically > because the result of the evaluation at the border MTA is the only thing > that should matter. I thus have some trouble understanding why "policy.ip" > and "policy.txt" are desirable things to include. And even if that were > not true, I'm concerned that "policy.ip" could be interpreted as an IP > address even though that's manifestly not what this is. > > Related: Section 3 of the draft appears to be commentary about what should go in TXT records, or how things querying DNSxLs should query and interpret TXT results. This doesn't seem to be appropriate for a document about Authentication-Results; it's implementation guidance for MTAs or receiving agents. About the only sentence I see in there that makes sense to include that's relevant to a registration action is the one about encoding non-ASCII content. -MSK --000000000000e36d9b058f08dcc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000e36d9b058f08dcc1-- From nobody Thu Aug 1 00:40:05 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 7B2D6120052 for ; Thu, 1 Aug 2019 00:40:03 -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 3Rx1kC-sMnpG for ; Thu, 1 Aug 2019 00:40:01 -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 8B0E012004C for ; Thu, 1 Aug 2019 00:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564645199; bh=KvbquqasqIHBLLI7VDAjOuz3571Cw73SuxYaT1bPdLM=; l=1710; h=To:References:From:Date:In-Reply-To; b=Asc8kRxbRzMu/Mnq/vWPOrHLFUOogRSZfIo/dayYHLi/OcZnS3RO3Yxx6IgPOpulH +MLcFDnqYDQnLXm1cuaHa4meGMVFteowFs4Yja69PJsX2gQPHCCLj9pvXppXwoD4qV c/qjTkhOWtSiUs0ArXIUH8HbCvBYF5ac51w+00yK9kDh1KiErmXmTiWQHxmQn Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC042.000000005D42974F.000039BB; Thu, 01 Aug 2019 09:39:59 +0200 To: dmarc@ietf.org References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <1209de12-5571-327c-53b1-568e8342a465@tana.it> Date: Thu, 1 Aug 2019 09:39:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 01 Aug 2019 07:40:04 -0000 On Wed 31/Jul/2019 12:46:00 +0200 Scott Kitterman wrote: >> Would it be possible to add a result of "quarantine"? Having dmarc=fail >> and dns.policy=quarantine leaves a good deal of interpretation to the MDA. >> If one could write dmarc=quarantine, a simple string search or regular >> expression would do. > That's a great example of why dns.policy= isn't the way to go. It's too > generic. If it's dmarc.policy=quarantine, there's no ambiguity. "dmarc" is already found in the methodspec. See below. > You can't put quarantine as the DMARC result, because that's not what it is. > The DMARC result is pass/fail/none. A tentative regex (assuming untrusted ones removed, and no deceptive comments) can be: if (/^Authentication-Results:.*dmarc\s*=\s*fail[^;]*dmarc\.policy\s*=\s*quarantine/) to "./Maildir/.Junk"; You can see that spelling the ptype is redundant. While it is important to report which published policy was applied, the choice of ptype boils down to a question of taste. At any rate, the code exemplified above is still too complicate to beat a well crafted comment. Consider: Authentication-Results: example.com; dmarc=fail dmarc.policy=quarantine (dmarc=quarantine); and if (/^Authentication-Results:.*dmarc\s*=\s*quarantine/) to "./Maildir/.Junk"; Since you mentioned that conveying the outcome of the method in a comment is not cool, I proposed to convey it in the result. I understand that the semantics of results aspired to be boolean, pass and non-pass. The existing flavors of non-pass, none, temperror, permerror and fail, exist in order to suggest the appropriate action. To quarantine is one appropriate action. Best Ale -- From nobody Thu Aug 1 02: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 565481200C3 for ; Thu, 1 Aug 2019 02:24:12 -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 4PvkF0Yif7eO for ; Thu, 1 Aug 2019 02:24:10 -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 39AC41200B1 for ; Thu, 1 Aug 2019 02:24:10 -0700 (PDT) Authentication-Results: mail.aegee.org/x719O6bC032645; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564651447; i=dkim+MSA-tls@aegee.org; r=y; bh=Shvb0MtcXBlxV4rM0w3KU4L+TvRXrhUrNQTb2tfNac4=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=YHYaUYzJJRgFHq+DAQmY2h9l76wgogqUndkdR2YdmHTYy5Mr9DssAE68CeTi0iGPA EJhChUDmf5KjaUvfHA3VxT8JiLn/FSB9nrt2nAq4olkKJV3drt1MDiyVnDckqKqeG4 MJsM3D7rCvGtCpOCm23IMf9ougwE+e56PrWoJMPp9GLgncGIoaA7m9yP0qH6HEHA2X Iy6oOvdNzPaUgNZ0a4M2wnLNiDmJymrjsv8OfHu5OjvOpgatVdBadDLocX45PipEgo GPr90FKRDSZcmN/2pvoT///ELncoORe40T8/GCAJPM6GvHDtJ1Gu4N0vB8TRbsbMXJ EYa79EPc7eNqOmdT4wegVgYOR75sXC+uxsXD21Pl4umDwBtCLYmR0jwiRDeZpSKWgL kG8y6XQqQ+9/SCsqZZs7I/PJcrIqOf4uIzqBxEzgtbnn7gdHocI7AZnrMXI9Qz4n1R EB1zsx1IpliSFlaZWpv9eOW58F2xmn600E5YcZ0FjFHbViyrr8fSYXZ3q6sf1gU9l7 GP7n4jw+xWcD2oLDO6WTYmDU2EQ02vRBpV0QzCrLPm++aBJIUkBKjWNOf8Bfaj+Esb hAj4etijK1gytSedX832lifMCaTCM0ebErX6uCYAc9guJpuqq2POlqXnvU9FAwvlLW tcICOTlVHBi5wJcfc491I1Es= Authentication-Results: mail.aegee.org/x719O6bC032645; 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 x719O6bC032645 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 1 Aug 2019 09:24:07 GMT Message-ID: <368bb159f7721bb1feb386aebdf1ff1922e671cb.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: "Murray S. Kucherawy" Cc: IETF DMARC WG Date: Thu, 01 Aug 2019 09:24:01 +0000 In-Reply-To: References: <187a4f8129f624d5590b553aff40489c8d24fb97.camel@aegee.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] if policy quarantine will be kept 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, 01 Aug 2019 09:24:12 -0000 Hello, yes, it requires different receivers to know each other capabilities. Here a new proposed wording, if policy quarantine will be kept: Messages, subject to the quarantine policy, directed to a single recipient that does not support the concept of quarantining, can be either accepted and delivered, accepted and discarded, accepted and bounced, or rejected at SMTP level. Messages, subject to the quarantine policy, directed to many recipients, some of which support the concept of quarantining, and the others not supporting this concept, can be either: * accepted, quarantined for the first group of recipients and discarded for the other recipients, * accepted, quarantined for the first group of recipients and delivered to the other recipients, * accepted, quarantined for the first group of recipients and bounced for the other recipients, * segmented, * rejected as whole, or * quarantined for the first group of recipients, discarded for the other recipients, and at the same time rejecting the message at SMTP level, spelling in the reply to which recipients the message was delivered and to which not. An example for a reply line for the last case is: 550-5.7.1 The mail was delivered in the Junk folder for user1@example.org and 550 user3@example.org. The mail was not delivered to user2@example.org. Discarding and bouncing are to be avoided. Accepting and delivering the message ignores completely the DMARC policy. Segmentation imposes delivery delays. This specification recommends in both cases overriding the policy and rejecting the message at SMTP level. For a message, subject to the quarantine policy, if the receiving server does not know whether a recipient supports the concept of quarantining, the recommendation is to override the policy and reject the message. [...] In the absense of failure reports, rejecting messages with failed DMARC validation allows the sender to determine for which messages the validation failed. When messages with failed DMARC validation are quarantined, the sender cannot find out for which messages the validation failed. I propose this text irrespective of whether policy quarantine will be kept: When the DMARC validation fails, the enacted actions are up to the receiving site. It can simultaneoulsy quarantine the message and reject it at SMTP level, spelling in the rejection reason that the message was delivered in the Junk folder. Regards Дилян On Wed, 2019-07-31 at 20:34 -0700, Murray S. Kucherawy wrote: > On Tue, Jul 30, 2019 at 7:29 AM Дилян Палаузов wrote: > > if policy quarantine will be kept, I propose including this text in the specification: > > > > Messages, subject to the quarantine policy, directed to a single recipient that does not support the concept of > > quarantining, can be either accepted and delivered, accepted and discarded, or rejected. > > > > Messages, subject to the quarantine policy, directed to many recipients, some of which support the concept of > > quarantining, and the others not supporting this concept, can be either: > > * accepted, quarantined for the first group of recipients and discarded for the other recipients, > > * accepted, quarantined for the first group of recipients and delivered to the other recipients, > > * segmented or > > * rejected as whole > > Doesn't this, as proposed, require different receivers to know each other's capabilities? > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Aug 1 06:48: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 572C012015A for ; Thu, 1 Aug 2019 06:48:50 -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=ADZ366Au; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=xwMxcVNn 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 5TWWuT9z39-M for ; Thu, 1 Aug 2019 06:48:48 -0700 (PDT) Received: from mail.winserver.com (winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 041F512008B for ; Thu, 1 Aug 2019 06:48:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2387; t=1564667319; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=8NpkbTbMGXmeq/1apykvKaUOlnw=; b=ADZ366AugMxIOpsMlDs8KcXzHahKhwAXqrLEn/cZqagavhfYNEi4cl7cqKlI14 l1YbYVZ4wcDDmK0HSTV/Ptqbn5+9Yio3VSU+MAVTtjC90lEphmqiTi7s0zVEbhDD jBkGHcqKodrKeCWaboAk/9xG81Zek4U+E0WQBZg0jOpCA= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Thu, 01 Aug 2019 09:48:39 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1164740237.61696.5164; Thu, 01 Aug 2019 09:48:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2387; t=1564667311; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4llHHp/ Vf/n/mb6UNbg8nX5tboqrP+q+4ard612C+hM=; b=xwMxcVNn1eLMYgcVACERdN9 tfQW6zBsDjpxQ19VvGWQo21iYea4C2jdTQIVboHkyHImc8hL6F5pqovNoysgsFf5 z6P/Ly18QYMl2Lxv8759U1PgrHKWkWbioIvfriLeFmG42OWA/cIJzDpXkujgW+kg IPL2kXTDWNbJDQuBKgkw= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Thu, 01 Aug 2019 09:48:30 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 18222671.9.1860; Thu, 01 Aug 2019 09:48:29 -0400 Message-ID: <5D42EDB5.10107@isdg.net> Date: Thu, 01 Aug 2019 09:48:37 -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: "Murray S. Kucherawy" , Tim Wicinski CC: IETF DMARC WG , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD?= =?UTF-8?B?0LfQvtCy?= , Alessandro Vesely References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> 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: Thu, 01 Aug 2019 13:48:50 -0000 On 7/31/2019 11:32 PM, Murray S. Kucherawy wrote: > On Sun, Jul 28, 2019 at 6:37 AM Tim Wicinski > wrote: > > From our end user point of view, I'm against abolishing > quarantine, even with its current shortcomings. > > > Why's that? > > -MSK, also hatless My opinion. How the receiver implements mail filters SHOULD always remain as local policy. We have always kept the concept open ended for all the DKIM Author Domain policy proposals, including SPF where hard failures (SPF -ALL, SSP Exclusive Policy, ADSP DISCARDABLE, DMARC reject/quarantine are hard failures) can be handled as follows: 1- Immediate permanent rejection at SMTP 1.1 - with SPF before or after DATA state. 1.2 - with a DKIM POLICY after DATA state 2- Accept at SMTP, disconnect, silent discard. 3- Accept at SMTP, disconnect, import into User's non-primary in-box, if any. With a reject policy, the Author Domain prefers #1 or #2. but it can be implemented all three ways by the receiver. The ultimate outcome is a domain preference for rejectable failures not to reach the user's eye balls. With quarantine, the Author Domain is requesting #3 type of mail handling because of concerns for false positives. Allow the user to see the mail, just in case. But what if the implementation site does not offer a "Quarantine" mail storage capable design model? If this type of implementation is not acceptable per DMARC design specification, then the spec will need to state this possibility: For Quarantine Policy support, the implementation SHOULD offer a multiple user mail folder storage and viewing capability. If the implementation can not offer quarantine support, then it SHOULD __________________________. The author domain MUST be aware not all receivers can support a "Junk" folder concept were quarantine mail can be separated from the user's main mail pickup in-box. So, I think, we should keep the quarantine policy because it does allow for the wider desirable design of for Mail Filtering Systems where multiple user folders can be supported and also for domains who are not yet 100% sure about issuing hard reject/discard directions. If we take it out, there is still going to be receivers who will perform a quarantine concept regardless of a hard reject policy. -- HLS From nobody Thu Aug 1 07:38: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 00634120169 for ; Thu, 1 Aug 2019 07:38: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, 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 J-G8QNmhJk0O for ; Thu, 1 Aug 2019 07:38:13 -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 B8AB112018F for ; Thu, 1 Aug 2019 07:38:12 -0700 (PDT) Authentication-Results: mail.aegee.org/x71Ec8OA003540; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564670289; i=dkim+MSA-tls@aegee.org; r=y; bh=LpFIeC7QyqeQ3afwcDUAxcUYDWLF7uX+L9UNQYjU2ec=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=VtZcELH8k11+GW0yEvLcjzrDsI4Vetp3V2HnTV2snLsErEmwCCm7f+vzsh+iXhA2t N7mAWC38MS1APKhh6cad81XYnY0IMU9YAOhPqIxrdiVif9ejRYsRZ8GkJvX5PQm4K1 2oJAqjidGdgVow8vCbgwqJ2dyNhkBJdxDWmMhJZvPpYDYoiQ5rN7YI9+E7QDKOlXsr mjlzie4WtkG4WDmlg8iWB7iwkE4jrXqDeUR5cfx0NhXyHzwRiEO9/cMQMZ0PoZ10wI laQTR5A58HldCzHu2bmxkSwchHQvLvqd2qs58AjCaNI3tWu7+qNUGO6NhuTBr0JoPW 1FrdYFb6LUTRkImc/uYFDOmCf7CY/ItBqdQohKLmgG67/VwcUu7mYUpxkTSOHOi0GT PeeVIByeAhC4YW96TMCPJOmJQ0hrf9wPQkikKJRibINWM1yq+g8rkgE3qQf1vOoOpV WhbYrVmBeOa6c8jifIay+t7Muo0/iTn4oN3yctYAUbwynlH9DLSnYuzJ3tNIwkbAsO JkUIh0lx3g1VkWnUUUylTrklq5sc0SKDNFO9P36ol0WRTcdpA6thSWf5rOvn+E7g+q 0i/VBLNquqzeoOSt3BcDWrMqXfE1szKJC23qeoYJfBmiRwydTYNlOutOQ93mCi7njG 3/rKh5ETPOKp80+ZrSqk5ZL8= Authentication-Results: mail.aegee.org/x71Ec8OA003540; 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 x71Ec8OA003540 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 1 Aug 2019 14:38:09 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, "Murray S. Kucherawy" , Tim Wicinski Cc: IETF DMARC WG , Alessandro Vesely Date: Thu, 01 Aug 2019 14:38:08 +0000 In-Reply-To: <5D42EDB5.10107@isdg.net> References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> <5D42EDB5.10107@isdg.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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: Thu, 01 Aug 2019 14:38:15 -0000 Hello Hector, you state, that a domain owner can request p=quarantine over p=reject because of concers of false positives. Why shall one have concers about false positives, but will not be willing to fix them? I do repeat myself, but the way to fix the false positives is to introduce p=reject, see which emails fail and are returned and then fix the DKIM implementation for that messages. That said, if you have concerns of false positives and want to get rid of them, the way to go is do p=reject. If there are concerns about false positives, but nobody wants to fix them, you end having an unreliable system. Besides, I do not see when a false positive happens, due DKIM stuff not running correctly, whose problem is this: • Of the sending domain owner, • Of the user sending the mail (the only one who has nothing to say, except switching the provider), • Of the site receiving the mail, • Of the user receiving the mail? Among several valid answers, a correct one is, that this is a problem of the one who has wrong DKIM implementation and this is either the sending or the receiving site. Since the problem is not of the sender, the sender shall have no say. Note, that quarintining a message for a user, that never checks her spam folder, is equivalent to discarding the message and for such users the choise is in practice reject or discard. On Thu, 2019-08-01 at 09:48 -0400, Hector Santos wrote: > On 7/31/2019 11:32 PM, Murray S. Kucherawy wrote: > > How the receiver implements mail filters SHOULD always remain as local > policy. > > [...] > > If we take quarantine out, there is still going to be receivers who will > perform a quarantine concept regardless of a hard reject policy. > This is not exactly what I’m proposing with abolishing policy quarantine. I propose, that there are only two policies that can be annouced by the domain owner: • “none”, meaning that not all mails have DKIM-Signature that alings to From: to that domain • “not none”, meaning that the domain owner announces, that all messages From: that (sub)domain are supposed to have valid, aligned DKIM-Signatures. For pragmatical reasons, the name for “not none” will be “reject”. Moreover, I propose, that when the policy is “not none”, the recipient decides how to punish messages, that fail DMARC validation and the specification elaborates the possibilitis. So, with “not none” policy, some recipients will do hard reject and others not. Just like sites which have not deployedd DMARC. In any case, if the consens is to keep policy quarantine, and the specification states, that implementations can allow receiving sites to override the policy to reject (or to quarantine) and implementations can allow individual users to override the policy (to reject or to quarantine), recommending what to do with messages that go simultaneously to users which have not overridden the policy and to users which have overriden the sender policy, then I am fine. Regards Дилян From nobody Thu Aug 1 09:32: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 DBD101201AA for ; Thu, 1 Aug 2019 09:32:50 -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 SQD5hmYZpchY for ; Thu, 1 Aug 2019 09:32: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 6DA1F1201A2 for ; Thu, 1 Aug 2019 09:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564677164; bh=PVNyVmT9EwdAT/k9vilCch7YoR6W9uCItIzALxiSdJs=; l=5800; h=To:References:From:Date:In-Reply-To; b=A/v3hxc2I1TLgFTOKXqtA+i4guLuYmTi6gB6x+n3iF3CW1B1nWZJCsOAawwBYBFtG aOjJXtyE4q4BLvSSupsmo82IESfDVoq2a1FHpT9kKmwKP7QKu+lsg+eCKJYKwvOKS9 xzxPbQXVc/JTdlAir5IDz3xuZbVM/88B8B+cXCz3y4M1DrHbQPUs1zCQUZKkl Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC056.000000005D43142B.000076D0; Thu, 01 Aug 2019 18:32:43 +0200 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> Date: Thu, 1 Aug 2019 18:32:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 01 Aug 2019 16:32:51 -0000 On Thu 01/Aug/2019 07:27:10 +0200 Murray S. Kucherawy wrote: > On Wed, Jul 31, 2019 at 9:40 PM Scott Kitterman > wrote: > >> Can we discuss this choice? I know this has been implemented already, so >> I'm at least slightly reluctant to do the semi-standard lets rename >> existing stuff dance that the IETF often does, but I really don't like >> this. There isn't an email authentication system out there that doesn't >> rely on DNS. I think DNS as a ptype is way too broad. Policy is even broader. What's wrong in being broad? Registering this ptype does not preclude future methods from using it as well. In fact, even if all email authentication systems rely on DNS, none of the properties registered thus far derive from there. Existing ptypes, body, header, smtp and policy, report data found in their respective areas, none of which is the DNS. >> Also, if I rsync a copy of the list and process it locally, is it still >> OK to use the dns ptype when there is no DNS involved? I do rsync a copy, and then serve it via rbldnsd (actually through a bind forward-only zone). MTAs will run a query using the DNS protocol anyway. Courier is smart enough to query an internal zone and report its public name. >> What about something like extpolicy: The property reported relates to an >> external policy input? Hm... >> Would you be willing to do something like that? If so, I think we could >> also register dns, but with status of decprecated since it's in use and >> documenting in use stuff is good. Then Courier can change at some point >> when it's convenient, but still be using a registered paramet.>> > > > > Thanks for commenting on this. I'm overdue to provide a review and > feedback. > > I rejected this application prior to RFC8601 primarily because the language > used then to restrict what goes in the registry didn't allow for > registrations of stuff that wasn't actually part of the message, and a DNS > whitelist or blacklist result is not (nor for example is the client IP > address, or the result of any query entirely external to the message body, > header, or even envelope). The good news is that the language of RFC8601 > is more relaxed, in particular in Section 2.3 it allows for a > property/ptype that covers "some other aspect of the message's handling", > so that's no longer a blocking factor. > > To counter Scott's point, "dns" is a ptype that would exist within the > method of "dnswl", so I think it's hard to see how it could be > misinterpreted. But I'd like to see how this discussion plays out. I can > see his point about "dns" being a rather broad ptype. > > Appendix C of RFC8601 goes to some length to discourage the practice of > including all the details that were inputs to the evaluation, specifically > because the result of the evaluation at the border MTA is the only thing > that should matter. I thus have some trouble understanding why "policy.ip" > and "policy.txt" are desirable things to include. Let me narrate a use case. Courier-MTA can be configured to reject on SPF -all early in the SMTP dialogue, except if whitelisted. It writes SPF as well as dnswl results in the header, but does not interpret the policy.ip. Downstream filters can interpret the field based on the dns.zone. I use that feature to pass messages tagged "Heuristic" by the antivirus filter if policy.ip has a positive trustworthiness. As a matter of fact, Courier stopped to query "ANY" some months ago. That way, I miss policy.txt. Its use was not automated, however. A few times I happened to manually retrieve it after delivery. If I had a domain-based reputation system available, I could use the domain name in policy.txt to make automated delivery decisions. > Related: > > Section 3 of the draft appears to be commentary about what should go in TXT > records, or how things querying DNSxLs should query and interpret TXT > results. This doesn't seem to be appropriate for a document about > Authentication-Results; it's implementation guidance for MTAs or receiving > agents. Yes, the last paragraph is guidance about querying ANY. It could go to an appendix or be stroked, if we want to go through another revision. The first paragraph is about how dnswl's may work. Rfc5782 just says "DNSWLs MAY have a TXT record that describes the reason for the entry." I agree it is slightly out of scope for registering the parameters. OTOH, I'd like to know more dnswl's in order to inform better on TXT record usage. > And even if that were not true, I'm concerned that "policy.ip" could be > interpreted as an IP address even though that's manifestly not what this > is. That's the reason why I wanted to call "dns.zone" the other property, which could also be expressed as an IP address. > Nevertheless, Scott's point about documenting current use is well taken and > I like his idea in principle. The only concern I have is that allowing > this directly into a "deprecated" status still reserves the name "dns" > should anyone later devise a use for it that's appropriate in breadth. I > suspect though we could just ask IANA to register both, one deprecated and > one current, should that somehow ever come to pass. Well, DNS is so broad that it's natural to expect that such ptype be used to report more properties. However, the way the registry is now structured, it is only possible to deprecate the dns.zone property, not the very dns ptype, which seems to be what Scott wishes. "The DNS zone of a DNSWL" is much like the wording an MTA configuration manual might use, isn't it? Best Ale -- https://tools.ietf.org/html/draft-vesely-authmethod-dnswl From nobody Thu Aug 1 13:29: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 022511201EE for ; Thu, 1 Aug 2019 13:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItEPjReUHHo2 for ; Thu, 1 Aug 2019 13:29:42 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 834A6120272 for ; Thu, 1 Aug 2019 13:29:42 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id j21so28867581uap.2 for ; Thu, 01 Aug 2019 13:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w5daKdZrCj++0lbOUYafJh6KdwmBA2fCR3QS3KGYEI8=; b=WKW8v2EIRLd2DKLommSZ3nBu8nLZW30a6tArb5/KhHAMtB/lhRn6k/Nazlgmf8TfPH nliahxXpO55jMpsPXL9YQalac38DKaLz7KwSTYYRHZ+DNKSUP2OPDSuqPsl6ADxIKAjV mZN0xucbyAzaesG0y/AflQ3xUo8YXtBosevcUovS9n1aKyIr1n2cEuxQXQdUbHfSvbjJ ZE07jbFVgUArYsVcwNiiB0MVWz6y1HTE2xX/xYIALX81mQtlMOiYGqq3e38m+8NY8/Ol yI0utbpKxt2K9ExZjldBhD6/GDV7YRIpz2Z6ZtU7wwM4h2Y2huRZo5sJ2bEfkoq7tYDw zsag== 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=w5daKdZrCj++0lbOUYafJh6KdwmBA2fCR3QS3KGYEI8=; b=Zyigxidm9+5sA0Ykh+oSX5cPCIpkseo5IpiEcIZLym1ZSl0575l2/p8f+5Ls2tCzk4 fcXwQxbiQ0vcAT77SuaZIVElWDh2a4m8R92nYgeaRYxpK0yWvaVvUY43vgI08YT3em+Y c7Sd0JI79q4RGcrpkqaaQsmU38+tRfgJV6w1kKswbkAE7eZkVK669wj0cebDUU2/uoXX ac8UkyfCq6uTZsU/Fjf71nzUG42kVo05wawW2lhkNIu3ufbZew+P5dFILzKXAq8dEoRk xCFhhvtjDtYRtiDFtIeC4EQcx7qzv/LSDP+ROVzNb0/Bh4ctMd8aFK5jOniAwlRslOqQ smCw== X-Gm-Message-State: APjAAAXV69k9D23gwFkBNxQVskDZ4kb0uNKcdTb150N6AK1yn9+PMXwj i07P1EPrfqhtwDqRBtc1nFmg+ubQksG79MpWapUAo/E= X-Google-Smtp-Source: APXvYqyM/8cwr/C3XwYiQPdHgwaT7wZc6KKL9sNTKkVMcBDBJgH3hkSJR+Wfw3OEm0Gu/IgFYDxxOfq9A3NQ8lkk9DU= X-Received: by 2002:ab0:614d:: with SMTP id w13mr53511uan.66.1564691380971; Thu, 01 Aug 2019 13:29:40 -0700 (PDT) MIME-Version: 1.0 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> <3b3e4f30-7060-b534-e5d7-46981d84e821@tana.it> In-Reply-To: <3b3e4f30-7060-b534-e5d7-46981d84e821@tana.it> From: Brandon Long Date: Thu, 1 Aug 2019 13:29:29 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f2c33b058f141975" 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: Thu, 01 Aug 2019 20:29:46 -0000 --000000000000f2c33b058f141975 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 30, 2019 at 1:27 AM Alessandro Vesely wrote: > > On multiple policies, only 4 of the latter 34 have p=quarantine; > sp=reject; the > other 30 have p=reject; sp=quarantine. By comparison, the previous 73 + 45 > have about the same ratio of p=hard/p=none; 45/28 for reject and 29/16 for > quarantine, so some 63% of those have p=hard; sp=none. Can one infer from > here > the intent of the 30 p=reject; sp=quarantine? > They've validated that all the senders for the main domain are authing, but haven't done so for the sub-domains. Or they don't send from the primary domain. > My feeling while looking at that data is that 'reject' is sometimes > considered > /better/ than 'quarantine', which I don't think is true. This confusion > can > originate from the sequential order implied by that passage of Section > 6.6.4 > that Steve quoted. I agree that that Section needs to be amended. In > particular, the effect of pct=0 on From: rewriting should be mentioned. I think many folks do think of it progressively. For example, quarantine can be overridden by the recipient, by filter or manually looking, whereas reject typically can only be overridden by the administrator. Quarantine also means that some percentage of people can fall for the spam/phish even if it's quarantined, whereas a reject is never seen by the receiver. Reject seems to be the end goal, but folks have a hard time getting there (hence the many companies sprung up to help people get there). Quarantine is a stepping stone because of the ability to override, and the visibility by the receivers (presumably the point of email is that the receivers want it) Brandon --000000000000f2c33b058f141975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 30, 2019 at 1:27 AM Aless= andro Vesely <vesely@tana.it> w= rote:

On multiple policies, only 4 of the latter 34 have p=3Dquarantine; sp=3Drej= ect; the
other 30 have p=3Dreject; sp=3Dquarantine.=C2=A0 By comparison, the previou= s 73 + 45
have about the same ratio of p=3Dhard/p=3Dnone; 45/28 for reject and 29/16 = for
quarantine, so some 63% of those have p=3Dhard; sp=3Dnone.=C2=A0 Can one in= fer from here
the intent of the 30 p=3Dreject; sp=3Dquarantine?

=
They've validated that all the senders for the main domain a= re authing, but haven't done so for the
sub-domains.=C2=A0 Or= they don't send from the primary domain.
=C2=A0
My feeling while looking at that data is that 'reject' is sometimes= considered
/better/ than 'quarantine', which I don't think is true.=C2=A0 = This confusion can
originate from the sequential order implied by that passage of Section 6.6.= 4
that Steve quoted.=C2=A0 I agree that that Section needs to be amended.=C2= =A0 In
particular, the effect of pct=3D0 on From: rewriting should be mentioned.

I think many folks do think of it progressiv= ely.=C2=A0 For example, quarantine can be overridden by the
recip= ient, by filter or manually looking, whereas reject typically can only be o= verridden by the=C2=A0
administrator.

Quarantine also mean= s that some percentage of people can fall for the spam/phish even if it'= ;s quarantined,
whereas a reject is never seen by the receiver.
Reject seems to be the end goal, but folks have a hard time getting t= here (hence the many companies sprung up
to help people get there= ).=C2=A0 Quarantine is a stepping stone because of the ability to override,= and the visibility by the
receivers (presumably the point of ema= il is that the receivers want it)

Brandon=C2=A0
--000000000000f2c33b058f141975-- From nobody Thu Aug 1 15:16:05 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 B66A612018C for ; Thu, 1 Aug 2019 15:16:04 -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=iaZ7DDHT; dkim=pass (2048-bit key) header.d=kitterman.com header.b=UtT09IMB 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 0S8ro6JaMCQl for ; Thu, 1 Aug 2019 15:16:03 -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 2BA7412001A for ; Thu, 1 Aug 2019 15:16:03 -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 DFCF7F807F3; Thu, 1 Aug 2019 18:15:31 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564697731; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=K9erpdxzUPmceDwFTV0N/uEiMkckfX0jAOD6k1BZ9Vc=; b=iaZ7DDHTKiA5w7B575k/U2Uy66GIPv+IExA7VRkg5KeBAuquCIZ58p9f NOW8bM3rdxFDIUYUHpiQpgeRzrXgBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564697731; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=K9erpdxzUPmceDwFTV0N/uEiMkckfX0jAOD6k1BZ9Vc=; b=UtT09IMBk9Vz7pwNTBzXy9CAvC9CMpgZUwMw/PD1CC7lYesibeJC4Xn2 PUWnMBVJh/qZDrVjLG7FO/Y7KyaDU1exJ+L30AZoMVff6OmLtxpHP6NXps jtQ1wVjzpvPk6B18EWb937doWoKnrP22myPdQ0kYJZwa8/kMYqDGJOW8XK UkuMf+aAtNplnSXYxYUoRh1s2m8J6DkAynbv+DMzcuZwDkEVxhpVendzwm H1bQLb1tvc81Yn2MaEgvE/DT+QC9UyxZ8GRyMAU4Yx/cHCsYFi9Tovic/V aNRRjA8DbPPeMb5C1NuqIKS05fXE0M9LprmrYnXjBLcTR/MMLstwaA== Received: from [10.67.225.129] (mobile-166-170-33-245.mycingular.net [166.170.33.245]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8AC41F8077C; Thu, 1 Aug 2019 18:15:31 -0400 (EDT) Date: Thu, 01 Aug 2019 22:15:30 +0000 In-Reply-To: <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 22:16:05 -0000 Taking a step back, iprev uses the policy ptype=2E It's also based on loca= l interpretation of DNS data=2E Why doesn't policy work for dnswl just lik= e for iprev? Scott K From nobody Thu Aug 1 20:14: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 78D6D1200B9 for ; Thu, 1 Aug 2019 20:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 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.201, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dw03wCJ8; dkim=pass (1536-bit key) header.d=taugh.com header.b=e8PCO++j 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 BaKo7rvmYvqp for ; Thu, 1 Aug 2019 20:14:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F5A1200A1 for ; Thu, 1 Aug 2019 20:14:03 -0700 (PDT) Received: (qmail 20091 invoked from network); 2 Aug 2019 03:14:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=4e78.5d43aa79.k1908; i=printer-iecc.com@submit.iecc.com; bh=/H1xdMWSjyMv8XbcRtS2ybmmxQOgbS1UwBasfDEKmv8=; b=dw03wCJ8YZErQ5/EXCERZ7Ek3/O+Ldd4YI3+48S7QHtRProrQJo3UEfg7AVF1uibcbFmpmo8ez+LF0zdmc3a4M0g5CAqE2TMwPYkANm+3fo2w7VE/6A2zdnWni1HSy+2s5Euvsyfst1MdNlH6ToloWBTRLXdGUvNxLnSYO9/UWvnyvSVnLqX/hM4vxhUJg66CXkQZoBkLjxaWoiUtT5M6ObeY+S/Sn/oXyUtUPLayRXViyF3fwWxEMJU6Y15dqU2 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=4e78.5d43aa79.k1908; olt=printer-iecc.com@submit.iecc.com; bh=/H1xdMWSjyMv8XbcRtS2ybmmxQOgbS1UwBasfDEKmv8=; b=e8PCO++jEAXmMAUmFysN0J0JrKvvby6Nq+RzaBEOJ0hLPqmUak0kKzupSBj37cTTQb/QD75hgvy4gLJRTScGrmMRjUyuRncjMvO7U/8329rgSEZVX2E+69OMGX28JO/tqvTJfY6u6P38ykdhdoi2NgpT7YxYrb6fGRzzha9u/8DkiM5zBy/0AQCWCkKRalMDchTWLq0K9hIxE4qDEZJzjOxlZo1Zl8JFlVJGBDRGG9fJLnL2OHE+KDGEAzhTJSxF 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, printer@iecc.com) via TCP; 02 Aug 2019 03:14:01 -0000 Received: by ary.qy (Postfix, from userid 501) id 2C5AD752163; Thu, 1 Aug 2019 23:14:01 -0400 (EDT) Date: 1 Aug 2019 23:14:01 -0400 Message-Id: <20190802031401.2C5AD752163@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <4600949.rz9u5RyGOV@l5580> 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] Reporting DMARC policy in A-R header fields 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, 02 Aug 2019 03:14:06 -0000 Catching up on my mail after a laptop disaster, ... In article <4600949.rz9u5RyGOV@l5580> you write: >I think comments should be free-form. If we want data that can be machine >parsed, we should specify it. > >I think the above works in ABNF terms. It's: > >Authentication-Results:" authserv-id; method=result ptype.property=value >ptype.property=value I agree. We all put the DKIM stuff in comments but that's silly. If it's worth recording, it's worth doing in a way that we all agree about and can parse. R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 1 23:18: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 B5F25120136 for ; Thu, 1 Aug 2019 23:18:38 -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 sdKVIaYMcEwE for ; Thu, 1 Aug 2019 23:18:37 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 A361B120135 for ; Thu, 1 Aug 2019 23:18:36 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id z28so17506197ljn.4 for ; Thu, 01 Aug 2019 23:18:36 -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=vjTR/AzCPA5B5d4oKbPLw4svRNmXUBlqz9mERRru8ck=; b=PKK4DUal22OXpxh25ZH/uo5Tud6eqylKDsdLJvLrMxW+iQ4q9Po+6skWeYUHmERtlL 8i8DKzzu1uKtgXaVTC64FsHXdKmzKLasNaA98/Grdl4oo3g/dCxuFpQD1RRZWj1IRgd5 jLCk3Pr81Ptps9QYGbVW3o1Nax+M60sfsDb6DNgynHXk2rAX1+YvsCx39bkCP6iekler fNk0m95R1GEupvt/tsI7jwGk8HIa/1GuseiCWGG50kBJ18iMoEREblL4DyQiVXw28amy FacYrPpPZAbCormFkzOHs/1CUsb5tWkklC87tgudT0oROTU1z9d5fNy0PlfMV99+w5qC V/3g== 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=vjTR/AzCPA5B5d4oKbPLw4svRNmXUBlqz9mERRru8ck=; b=RoJ9jp735LHvPVTEZdEdmPEdn7cTPaDbvK9NPGCSkoD3KCf6LQzD+ueag+5fgdP7Ig KsqRd6LVT0BmqoiJocCg6JHr2/VSG89nmGEeYIzluGMSvh+eq7qnhzKkQ8RkJX7VVElJ 6Xtr8A8HZWnHXKgVWOFDbUiwSPJROjgMQephSy35O3Vy+ab1Jn1FAFbfZO+W4dsFrTvs mVhF4NanQXZkG1Jk2GKq5sb4lJl0GMVIUaSZciuKnOlTbIlZf4m5R+Zc+A0FTdm6RlTT DSaeYpacdK9NETJ3ul9rwOAGe7q1YpyUyceMctJDI6DhmjYjBsttyIIu1Rk4/H0mFqZd woCw== X-Gm-Message-State: APjAAAXYT2NP6nX0Z9741CW9+hi9EBc6o5NHo9ehyfIjZf4K/aQTuyN/ DwMKY3tvEMYIcw+NslbEgzs1eDm9OgripG3g8wo= X-Google-Smtp-Source: APXvYqwcbglV08DcGk/LCXOMTOonIACCxirbdrsn1KBjds7NFh/I2T663uqVOW2KKIU+lYipAT0hZy2Q9Jqpe7sGLCE= X-Received: by 2002:a2e:88d3:: with SMTP id a19mr23446586ljk.32.1564726714681; Thu, 01 Aug 2019 23:18:34 -0700 (PDT) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: "Murray S. Kucherawy" Date: Thu, 1 Aug 2019 23:18:20 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ffcc6c058f1c5311" 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: Fri, 02 Aug 2019 06:18:39 -0000 --000000000000ffcc6c058f1c5311 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 1, 2019 at 9:32 AM Alessandro Vesely wrote: > Let me narrate a use case. Courier-MTA can be configured to reject on SPF > -all > early in the SMTP dialogue, except if whitelisted. It writes SPF as well > as > dnswl results in the header, but does not interpret the policy.ip. > Downstream > filters can interpret the field based on the dns.zone. I use that feature > to > pass messages tagged "Heuristic" by the antivirus filter if policy.ip has a > positive trustworthiness. > I think this is a bit unusual, but RFC8601 doesn't preclude it. Seems to me you're effectively throwing away the result, "pass" or "fail", if downstream agents actually know more about the applied algorithm than the border MTA adding it. > Yes, the last paragraph is guidance about querying ANY. It could go to an > appendix or be stroked, if we want to go through another revision. > > The first paragraph is about how dnswl's may work. Rfc5782 just says > "DNSWLs > MAY have a TXT record that describes the reason for the entry." I agree > it is > slightly out of scope for registering the parameters. OTOH, I'd like to > know > more dnswl's in order to inform better on TXT record usage. > As long as the text is focused on the registration and not providing opinion about RFC5782, it's fine. I'm not so sure where the current text lands. -MSK --000000000000ffcc6c058f1c5311 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2019 at 9:32 AM Alessandro= Vesely <vesely@tana.it> wrote:=
Let me narrate a use case.=C2=A0 Courier-MTA can be configured = to reject on SPF -all
early in the SMTP dialogue, except if whitelisted.=C2=A0 It writes SPF as w= ell as
dnswl results in the header, but does not interpret the policy.ip.=C2=A0 Do= wnstream
filters can interpret the field based on the dns.zone.=C2=A0 I use that fea= ture to
pass messages tagged "Heuristic" by the antivirus filter if polic= y.ip has a
positive trustworthiness.

I think this = is a bit unusual, but RFC8601 doesn't preclude it.=C2=A0 Seems to me yo= u're effectively throwing away the result, "pass" or "fa= il", if downstream agents actually know more about the applied algorit= hm than the border MTA adding it.
=C2=A0
Yes, the last paragraph is guidance about query= ing ANY.=C2=A0 It could go to an
appendix or be stroked, if we want to go through another revision.

The first paragraph is about how dnswl's may work.=C2=A0 Rfc5782 just s= ays "DNSWLs
MAY have a TXT record that describes the reason for the entry."=C2=A0 = I agree it is
slightly out of scope for registering the parameters.=C2=A0 OTOH, I'd l= ike to know
more dnswl's in order to inform better on TXT record usage.

As long as the text is focused on the registration= and not providing opinion about RFC5782, it's fine.=C2=A0 I'm not = so sure where the current text lands.

-MSK
--000000000000ffcc6c058f1c5311-- From nobody Thu Aug 1 23:23: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 6F83F120135 for ; Thu, 1 Aug 2019 23:23:42 -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=cleO7+fL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bEId8Ghw 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 iw7H4TZu2Wwb for ; Thu, 1 Aug 2019 23:23:40 -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 AB73612002E for ; Thu, 1 Aug 2019 23:23:40 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C208321F85 for ; Fri, 2 Aug 2019 02:23:39 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Fri, 02 Aug 2019 02:23:39 -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=fm1; bh=HWZE4LlWNViIUuk0669Q3RNbLkRj9j2 Og6dGV0YOv+g=; b=cleO7+fLPMvIYto90dpfwW6L0aFhUTxmobDJFCRsIcCr8tu 2ShmT22PaXmd9W6EqtkIOvSPlbQo0prgyAqoYN7HhffQAoHkDHrO45ufYYHF1eGj ISSa7b5mZa/kH5jHGkONrvgRUUKGIVSzKiPOTXETfZriEEZawBQ5ueATKO1/Vff4 +CA6OkbhwN1EOXWh7Jmu6FGhb8HeDkguKZSvbcFYB4nqDb0N5NQVYymy5i6Z22YT +qkVhss3vYxPHqNOCgcCg4q710w5ReWlGkEfqflJfm49QMKPGa6kPK5POob6lzvi MOv2gh/uxYIs+x5wqs2X88yJpvmojmbr5jffO8w== 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=HWZE4L lWNViIUuk0669Q3RNbLkRj9j2Og6dGV0YOv+g=; b=bEId8GhwJICBBq1zYAaoWi 2wfJLD65sL5lW62VBXZsRmrnSj90QO/qiqDOJ74hgyvF1Xeqoink10WEk6jKvoJM lhW5x450wlC2MizoyybamS9nUdFVRCiTThYr3XYbP+FZDLAQzV2ViVxRMn4eo4fb UtJl+VIuGgYRUa4jjqlo6u1HQ+HWsUki+f9K4VNZbjfYFyhNaN9mx87/8ab+856K e7Zqt4SfN7a7VH+VZJx9j9FM1gOuYwjNJQ/WpA+U3diquSDsu8rOaRI1FALQNQ1r fRpjOzG+Gp8ZKUG6dxSGy2pm6/Da7aW/XVCXXwhSevD276HV4xiiLHqVUn4tTt5w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleekgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucfrrghrrghmpehmrghilhhfrh homhepshhtrghnsehglhihphhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F229D1400EE; Fri, 2 Aug 2019 02:23:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-799-g925e343-fmstable-20190729v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <20190802031401.2C5AD752163@ary.qy> References: <20190802031401.2C5AD752163@ary.qy> Date: Fri, 02 Aug 2019 02:23:37 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=258ba014b92e49458c64c1d848f1143a Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 02 Aug 2019 06:23:42 -0000 --258ba014b92e49458c64c1d848f1143a Content-Type: text/plain On Thu, Aug 1, 2019, at 11:14 PM, John Levine wrote: > Catching up on my mail after a laptop disaster, ... > > In article <4600949.rz9u5RyGOV@l5580> you write: > >I think comments should be free-form. If we want data that can be machine > >parsed, we should specify it. > > > >I think the above works in ABNF terms. It's: > > > >Authentication-Results:" authserv-id; method=result ptype.property=value > >ptype.property=value > > I agree. We all put the DKIM stuff in comments but that's silly. If > it's worth recording, it's worth doing in a way that we all agree > about and can parse. Yes please. Stan --258ba014b92e49458c64c1d848f1143a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2019, at 11:14 PM, John Levine wrote:
Catching up on my mail after a laptop disaster, ...

In = article <4600949.rz9u5RyGOV@l5580> you write:
>I think comments should be free-form.  If = we want data that can be machine 
>parsed, we should specify it.
>
>I thi= nk the above works in ABNF terms.  It's:
>
>Aut= hentication-Results:" authserv-id; method=3Dresult ptype.property=3Dvalu= e 
>ptype.property=3D= value

I agree.  We all put the DKIM stuff in comment= s but that's silly.  If
= it's worth recording, it's worth doing in a way that we all agree
about and can parse.

Yes please.

Stan

<= /body> --258ba014b92e49458c64c1d848f1143a-- From nobody Fri Aug 2 03:00: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 B202C12007A for ; Fri, 2 Aug 2019 03:00:22 -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 VEfldhp4boAS for ; Fri, 2 Aug 2019 03:00:01 -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 080EC12004E for ; Fri, 2 Aug 2019 03:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564739999; bh=Znue5edqXI04H0iw+BGskbgegG8lwxsQYMhtYTKYqmw=; l=1143; h=To:References:From:Date:In-Reply-To; b=AVE3aBUkv4yKEjQGEB2PM9cxc+7jd9Uvj28QtCb5QB7lBAFLB3YeTDg0r9K8YMqyR K8dXr+frdfL69WNWAEK6OVL6bcxTvWG8tMlPFQVXN3E4AjpPKQio4vcmGZ6wmbgYzx DKFKdX5BnVql4Bmx3BcgghzzU5PcyIasPcy03F3TG0OMI05PZjPoO+1NjPVDI Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC02F.000000005D44099E.000030A7; Fri, 02 Aug 2019 11:59:58 +0200 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Fri, 2 Aug 2019 11:59:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 10:00:23 -0000 On Fri 02/Aug/2019 00:15:30 +0200 Scott Kitterman wrote: > Taking a step back, iprev uses the policy ptype. It's also based on local interpretation of DNS data. Why doesn't policy work for dnswl just like for iprev? Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, does not contain the term "policy". My recollection is that reporting the client IP is immaterial, as for SPF. The term policy.iprev is certainly misleading, since the value is not related to a locally-defined policy, and is not a reversed ip. To stick with A-R semantics, it should have been named tcp.ip, remote.ip or some such. If a property warrants deprecation, it's policy.iprev. Now for dnswl. Knowing which zone was queried is substantial in order to interpret policy.ip, because there is no standard format. Yet, an implementation could just throw a DNS query to a given local IP, instead of a FQDN to the default DNS server. In that case, one would have, for example: dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2 In that case one can hardly tell which is which. A meaningful ptype helps. Best Ale -- From nobody Fri Aug 2 03:10: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 C93701202A4 for ; Fri, 2 Aug 2019 03:10: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 6utIdTGcehE2 for ; Fri, 2 Aug 2019 03:10: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 26EB81200C1 for ; Fri, 2 Aug 2019 03:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564740645; bh=W8YMlc4kViZhEXdNo6lJcmu0nRuVMv3oZooV4fM2YC0=; l=1313; h=To:References:From:Date:In-Reply-To; b=A5sP/4kTctvXybzlO7di/eOcfwGBthjSaAkeOSpOTyewMDbgVhn+4k4jrO0HZ/P5Q bFaSZ3vbjmUWXT91SuZB1Ovu4Iqogm5roWlBHeWulveU5OiJXEbLxYTEUE9IT9vWJQ /nIFGHqgIzMEkvP2oHTuO8lnKEQd/r8UlxME68++x+wmzA8n1v+eZBQhNWkHu Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC042.000000005D440C24.00003220; Fri, 02 Aug 2019 12:10:44 +0200 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Fri, 2 Aug 2019 12:10:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 02 Aug 2019 10:10:53 -0000 On Fri 02/Aug/2019 08:18:20 +0200 Murray S. Kucherawy wrote: > On Thu, Aug 1, 2019 at 9:32 AM Alessandro Vesely wrote: > >> Let me narrate a use case. Courier-MTA can be configured to reject on >> SPF -all early in the SMTP dialogue, except if whitelisted. It writes SPF >> as well as dnswl results in the header, but does not interpret the >> policy.ip. Downstream filters can interpret the field based on the >> dns.zone. I use that feature to pass messages tagged "Heuristic" by the >> antivirus filter if policy.ip has a positive trustworthiness.>> > > I think this is a bit unusual, but RFC8601 doesn't preclude it. Seems to me > you're effectively throwing away the result, "pass" or "fail", if downstream > agents actually know more about the applied algorithm than the border MTA > adding it. In the case at hand, in fact, failed lookups are never reported. If no dnswl query is configured, it makes no sense to configure which trustworthiness value is needed to counterbalance which negative heuristics. The "pass" just confirms it's mere presence. In general, however, a filter may want to distinguish dnswl!=pass from no dnswl query at all. A negative query (NXDOMAIN or NO DATA) would be dnswl=none. No "fail" is provided for in the I-D. Best Ale -- From nobody Fri Aug 2 04:26:34 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 8F20512004A for ; Fri, 2 Aug 2019 04:26:32 -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, MIME_QP_LONG_LINE=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 ui502J4BK4sF for ; Fri, 2 Aug 2019 04:26:31 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2787120033 for ; Fri, 2 Aug 2019 04:26:30 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id i10so38071268iol.13 for ; Fri, 02 Aug 2019 04:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/rwim81GaLd4tD/oQDyrZPbA608/BJHuSd0UQcQjdfQ=; b=rDvsUnqYFBnOS5u0zFo+Fq0TJxd5HiuWcUqwjOYZujBml6IEkvGf915YkeH6CAVMWi zkmkvzcvQoWeKGe/odAtpMHs/iAkE0zE89Bec+CNgM5FraH2XtStmUF63b/PForzdQBI nEMQeVKZzpKwKtZ5r0TOesVUrMD2+ypF2FCojiPAUvmV4qZ6YolyggX6/Fv8WW/a+6GL WHv7fvz1y7X8lDslJcV28TqzNv6PwIj/KJ8FhD3plApuR0EPbz5T2VrOYvSzVbP57oHA qNC5HjPJMCEbjT/r35nlV0EG6KKIt9o2spvSjybHVXEvv9F4zLKK2Sv/NZ9QddqAeIjI gh4Q== 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=/rwim81GaLd4tD/oQDyrZPbA608/BJHuSd0UQcQjdfQ=; b=RmBJu5ZxR3VqIM2nCYphRwvpiZIco6xMP4MT+cQK8my7+HFInI0SfFKiB6/Hght8S3 GkDFnvpotmZGB3HTHMszR94vicxuYi544KufEX+Ske0Ipq9d7wcDXy83GJNx3cXI/3r8 NB/waggkd07UPwRlA1vECNTRWdz+6Kgqg+JAmX9uFOPcLDlu5N4dXkDanSYO0YLPUch2 GQ9rAMv/mJVJc7J3zELDp7xtrZOeTNs8Q8jNwOIXnXaZMwYf3c7eRTeYMZhD30wk3XvG w3yfkcNieFcm9az007isnO2dKu5XoMdiZuWynTHPWUfq3gY0GT5nHo/xJ1ec/gy/xPQz 1OmQ== X-Gm-Message-State: APjAAAVSTSTdnbqJC4fp2darZo11sdDzLt5fIWSfcpSTQXYzuGap8caa wy9FhYVmeDpgbvDoh6KHWPDaiFPu X-Google-Smtp-Source: APXvYqx11I2iNUye56LfFYqBuHqb+H0E+CIgh518if2Rd3l8V3vcmi/xAGlroielKBhnVi5DvLS+PQ== X-Received: by 2002:a02:ce37:: with SMTP id v23mr28786898jar.2.1564745189999; Fri, 02 Aug 2019 04:26:29 -0700 (PDT) Received: from [192.168.1.34] ([50.110.73.130]) by smtp.gmail.com with ESMTPSA id k26sm56157500ios.38.2019.08.02.04.26.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 04:26:29 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-417CE4A4-503B-47DC-9BD1-B870BAC3FD86 Mime-Version: 1.0 (1.0) From: tjw ietf X-Mailer: iPhone Mail (16G77) In-Reply-To: Date: Fri, 2 Aug 2019 07:26:28 -0400 Cc: dmarc@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <13954F80-F37D-488A-A810-A0942750A1D2@gmail.com> References: <20190802031401.2C5AD752163@ary.qy> To: Stan Kalisch Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 02 Aug 2019 11:26:33 -0000 --Apple-Mail-417CE4A4-503B-47DC-9BD1-B870BAC3FD86 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 No hats =46rom my high tech gadget > On Aug 2, 2019, at 02:23, Stan Kalisch wrote= : >=20 >> On Thu, Aug 1, 2019, at 11:14 PM, John Levine wrote: >> Catching up on my mail after a laptop disaster, ... >>=20 >> In article <4600949.rz9u5RyGOV@l5580> you write: >> >I think comments should be free-form. If we want data that can be machi= ne=20 >> >parsed, we should specify it. >> > >> >I think the above works in ABNF terms. It's: >> > >> >Authentication-Results:" authserv-id; method=3Dresult ptype.property=3Dv= alue=20 >> >ptype.property=3Dvalue >>=20 >> I agree. We all put the DKIM stuff in comments but that's silly. If >> it's worth recording, it's worth doing in a way that we all agree >> about and can parse. >=20 > Yes please. >=20 >=20 > Stan >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-417CE4A4-503B-47DC-9BD1-B870BAC3FD86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1

No hats

=46rom my high tech gadget

On Aug 2, 2019, at 02:23, Stan Kalisch <stan@glyphein.mailforce.net> wrote:
On Thu, Aug 1, 2019, at 11:14 PM, John Levine wrote:=
Catching up on my mail after a laptop disaster, ...

In article &= lt;4600949.rz9u5RyGOV@l5580> you write:
>I think comments should be free-form.  If we want data th= at can be machine 
>parse= d, we should specify it.
>
=
>I think the above works in ABNF t= erms.  It's:
>
<= div style=3D"font-family:Arial;">>Authentication-Results:" authserv-id; m= ethod=3Dresult ptype.property=3Dvalue 
>ptype.property=3Dvalue

I agree.  We all put t= he DKIM stuff in comments but that's silly.  If
it's worth recording, it's worth doing in a way that we a= ll agree
about and can parse.
=

Yes please.
=

Stan

=
______________= _________________________________
dmarc mailing list<= br>dmarc@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dmarc
= --Apple-Mail-417CE4A4-503B-47DC-9BD1-B870BAC3FD86-- From nobody Fri Aug 2 09:00: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 06A10120662 for ; Fri, 2 Aug 2019 09:00: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, 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 njVw7HoNxKBQ for ; Fri, 2 Aug 2019 09:00:16 -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 AD73F120659 for ; Fri, 2 Aug 2019 09:00:15 -0700 (PDT) Authentication-Results: mail.aegee.org/x72G0Bh9024373; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564761612; i=dkim+MSA-tls@aegee.org; r=y; bh=2n86Bt+6a4dKgvzwq4qAYTmbhW4UYzcMjonJCirwO9M=; h=Subject:From:To:Date; b=ev0sMFYHqSUfKgWFkCt3Q5optdqWi6xSvDgiMvHVSaxULQTwbLVa7HUnPDswMI9zf 2pLkx4LWKTe+VcgOYSnUsaS3lzYZJWLSUCk/3tndhLBUUmDtGgLX4J0AMI9yYzS5H8 wlmXHOWuULUuCsCY/rHYSQIi3XZ8aPpw+Y+SmiJiNveytSRduprQOU9wuriuzDwqgf BRyc7mbhDOv5xIXzevVhoah7B6AkamvYDGpNEfz5Y2mw4g8KxV7vBb+zmIOG4Gy1dr 8+OAry8pnVN8VI3Rf0jPOvhUSh515YZArKQZMQbM1Yfceod4/m3kxoE+XZTiULi4CW 6WHTk3FZKAtvFwnYSaKjQO5Xd0IROnJy/1rIbuF4Nl4jrIPOhyen3krm+eNrAM/rX+ QSim5I4HzVA/AGCebwrMrXZgH+ZjVaKwI12Q1DpyV361D9oY3Ty8jFuFiroDJdy+7M kyzDqLkeM0qhGAW6wGIexH/ZAEFWDkoR24UNE7SDHVeGzEhz3T3BlZs/z0j6xt8QeY lSp1JO5DRaQEvY5JQ2AoR+5j/dJ4SnQFmPz3lT6GjB1OyU+6/AlBsD5+jymx2DdX0H /vWqoy+MdCKb+ki+ZUgbs6Qv3R2h1ShHuB6whM3iI8M9T5BpHefg61CbaTTqV3bEYw 9ak0qWu53BNR1cFiUd1u94gs= Authentication-Results: mail.aegee.org/x72G0Bh9024373; 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 x72G0Bh9024373 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 2 Aug 2019 16:00:12 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 Date: Fri, 02 Aug 2019 16:00:11 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] ESC for Failed DMARC Validation 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, 02 Aug 2019 16:00:18 -0000 Hello, why sites do not sent failure reports? Will a site, not sending failure report, be willing to use an Enhanced Status Code, to signal, that the DKIM/SPF implementations of the receiver and sender disagree? * * * New Enhanced Status Code for Failed DMARC Validation Code: X.7.30 Assocaited basic status code: Any Description: Used as partial substitution to failure reports, when DMARC validation fails. 250 2.7.30 means, that the message was delivered, ordinary or as junk, despite failed DMARC validation. 550 5.7.30 is used when the message is rejected, because the DMARC validation failed. This status code is only usefull, when the receiving site does not send failure reports. Regards Дилян From nobody Fri Aug 2 09:24: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 0C19412016E for ; Fri, 2 Aug 2019 09:24:49 -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 0RUTcbBZYt0t for ; Fri, 2 Aug 2019 09:24:47 -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 DF64712015E for ; Fri, 2 Aug 2019 09:24:46 -0700 (PDT) Authentication-Results: mail.aegee.org/x72GOhkr029799; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564763084; i=dkim+MSA-tls@aegee.org; r=y; bh=L5RJaWiPCw1MJKUzxo2pyzOorQf33TViYpSdHcTqIww=; h=Subject:From:To:Date; b=noYEmbGwd3Bo81BJ8Zt90vafMnDt85W3YeYe1JDT6lDiLJNbOiD7LKJjaMFijXh+7 D3B6AHKUGzMrXzgJszUIhovhSJn8TLpA/G6e4V0INGmCm71BrEKZ3KG23CqMAocXwz U8M/xs2j6PKl/3GnB9X2syM+heevbZRwEEYRCvvpc+nHBTrzMv3z5SApVQzAk8UhLy PFUYhNK1uZnr0mqru0zV9DaJUlGBqtdeAmwYMv+o2nWCqCfPaAdFVKjqohG13yatml AYJBzMgC5cZxPyTP4QiM1KRlV+c/Oi9EObWPYlsqeHewxP0KA3DKRQruWv5Mmacm0L S7bInJuW3BCoFzmryOY3vKzAqS58P9hKoAaFpCHxYK0NEDHtDj5gZZHoNgpOF2abi4 xvNJaYdHZ44hPWjNlYWeDkF0Ez0YXSju95QYVh8/NEcr64v0g9Xq7aepk6tptJwkxP OVDmGP1p4M1A7bwUucqZ4rCoJUFezpj18zodLIncIk7PDY1W+XhrBYPUxJ4l+ReLjI Urgz28qg6hER7OEFrt/ArJbe+1AW+A3BxjoHw+qdxAALFv6AC6z01qZOqcJJWKNUzq m5EY/YFdECcKhtVo7ZlhHOix5uFMne+LcnhzUVmxgLc19tIJlz6kNkX8OFs9qpds/g Sl2PFubwTZ1/2DdL+a25JPZw= Authentication-Results: mail.aegee.org/x72GOhkr029799; 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 x72GOhkr029799 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 2 Aug 2019 16:24:44 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 Date: Fri, 02 Aug 2019 16:24:43 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] DMARC and Redirecting Messages 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, 02 Aug 2019 16:24:49 -0000 Hello, current text in https://tools.ietf.org/html/rfc7489#section-6 (DMARC Policy): Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing [... and SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report (see Section 7.2).] I propose this amendment to the first part of the sentance, (writen in a more abstract way, where the receiving site decides on the policy. The wording is subject to further adjustments): * * * DMARC and Redirecting Messages For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the policy is 100 the recommendation is not to redirect the message but reject it at SMTP level. The rationale is, that this message might be evaluated by the next hop site as Spam, while this hop does not consider the message as spam. In turn, the next hop can conclude, that this hop is sending spam. If the next hop decides to apply DMARC policy reject for the domain of the message, this hop will have to generate a bounce for the message, risking to be blacklisted by some backscatters IP reputation lists. For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the policy is between 1 and 99, the recommendation is to reject the message at SMTP level and not forward it further. For redirected messages, the PCT sampling is applied at least twice, thus there is a probabily that the next hop rejects the message based on the PCT parameter, even if this hop has calculated not to reject the message. It is in unknown, whether the next hop will reject or quarantine messages failing DMARC validation and from the sender's perspective there is no difference, whether this hop or the next hop will reject the message. The recommendations above do not fully apply, when the current hop changes the From: address, as if the recipient on the next hop were a mailing list with one recipient, doing From: mungling. It is not recommended to tell the sender that the message was delivered in the Junk folder of the recipient, and to forward the message further, as the sender can get two rejections for the same message, from two different hops, which is confusing. This can happen, even if the From: address is mungled. From nobody Fri Aug 2 10:18:30 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 DAA76120735 for ; Fri, 2 Aug 2019 10:18:27 -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 v-pYYlZrodLQ for ; Fri, 2 Aug 2019 10:18:26 -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 21327120287 for ; Fri, 2 Aug 2019 10:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564766304; bh=oGKLU5FPc2/RNocI7/4ikjucdOBB5JEStBT2BVi80Rc=; l=1478; h=To:References:From:Date:In-Reply-To; b=DjvojIbcXwKwDtUtPVcjuJzjPgzHKxrXj2GeFSkQ2J88mb0BtcJbZVSgwLXFAL6LA NyR09dLmEBTldAmEg1p4vZHwPaz3ByB2k6w5YAEQUQu7q78iCeTHxEyNszs0Bn0lVM klhxWcMggUS4HlkzH1CLfyWGy7pEdS897tDXDPHPUS9gAsdcu3tRFJ1QcAjWc Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC086.000000005D447060.0000634A; Fri, 02 Aug 2019 19:18:24 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> Date: Fri, 2 Aug 2019 19:18:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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] ESC for Failed DMARC Validation 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, 02 Aug 2019 17:18:28 -0000 Hi Dilyan, I'm not clear if you refer to the "DSN" extension (rfc3461). In fact, positive DSNs contain the A-R header field, and so can inform the sender when a message is accepted although some of SPF/ DKIM/ DMARC failed. I don't send failure reports, as they look plenty of privacy risks. Perhaps they could be sent to trusted sites only, but that way they'd lose generality. It's unfortunate that FR seem to be the only means to tell unwanted failures from real spam/ phishing successfully blocked by the protocol. Perhaps that distinction could be added to aggregate reports, even if it's not an exact science. Best Ale On Fri 02/Aug/2019 18:00:11 +0200 Дилян Палаузов wrote: > > why sites do not sent failure reports? > > Will a site, not sending failure report, be willing to use an Enhanced Status Code, to signal, that the DKIM/SPF > implementations of the receiver and sender disagree? > > * * * New Enhanced Status Code for Failed DMARC Validation > > Code: X.7.30 > Assocaited basic status code: Any > Description: Used as partial substitution to failure reports, when DMARC validation fails. 250 2.7.30 means, that the > message was delivered, ordinary or as junk, despite failed DMARC validation. 550 5.7.30 is used when the message is > rejected, because the DMARC validation failed. This status code is only usefull, when the receiving site does not send > failure reports. > > Regards > Дилян -- From nobody Fri Aug 2 10:23: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 09390120750 for ; Fri, 2 Aug 2019 10:23:09 -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 unV90pjxY7Hv for ; Fri, 2 Aug 2019 10:23:06 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 C09BE120746 for ; Fri, 2 Aug 2019 10:23:06 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id z3so12654632iog.0 for ; Fri, 02 Aug 2019 10:23:06 -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=pWlYAx4EjgUeRh1iMbpM+8UBUZO5fOH64WDWAMVRzOE=; b=D30l/ZZFm9WFFaE16zf/6rdlhtxvViBOy6wcKUh4kTG2cY/i+kU6pkl0vpJoP1/gA5 eZMlnBEYSueJ7zsGplSpcZpKC9R2vJXKqqrbSAH4WNvtyOkR62qq84cro81YYRTm8211 nc7wNPNKta18Lz8jLTsoOevFiY2gxLXIrhnfo= 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=pWlYAx4EjgUeRh1iMbpM+8UBUZO5fOH64WDWAMVRzOE=; b=CMsrd3GHyDr/ia4mVJu+V+hXaBB8w68buD3WvWi9+bO8kHDuAVjl1p30h8clQEIKZ2 iz9kNVvcVe0skgRTn1sbIzZp0ftB5yE/NJQiZv3GynXzWqWFi33RUM/kqXrH6Qu9sYVP ljXj8UjhtQ6grD3fXOgQfyVYPuszuuOMNQLRbhaarwgDqxAx+tDDxL/J5FkhBnA/r51L zDrC17yXRtoQlvy1iwKHF/VQaxMZlV9P6T3XDqtijOTePXR14fQt6M/hFAf3teeBXHcQ 6+EPq6cjr4R3eJfLVERsuXEPyDCY6bckU6cvsXLlniPQVBE4kZK9KAvyU5qep+CaajMS lZ4Q== X-Gm-Message-State: APjAAAUwRLR15SiDLSx8CWFoIDFtuRhC2AuXBsN08BHHCxjRsVIGyC33 gMZOfiOs9fmfmNciVNEUKRzAN3g5eaLxu4O28dVmbHORok8= X-Google-Smtp-Source: APXvYqwiUEzSwGXNrIJ08GU8VgFL0zJtcyghL6p1KiNVtw96WyBe14wEgkV3eW0OrAEYiyLG4BxLl2qD2Z1/ROcR138= X-Received: by 2002:a6b:f607:: with SMTP id n7mr90259653ioh.263.1564766585634; Fri, 02 Aug 2019 10:23:05 -0700 (PDT) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 2 Aug 2019 10:22:50 -0700 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007e5507058f259cc7" Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 17:23:09 -0000 --0000000000007e5507058f259cc7 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: > To stick with A-R semantics, it should have been named > tcp.ip, remote.ip or some such. > Note that RFC8617 section 10.2 ( https://tools.ietf.org/html/rfc8617#section-10.2) does add in an smtp.remote-ip method item. --Kurt --0000000000007e5507058f259cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 2, 2019 at 3:00 AM Alessandro= Vesely <vesely@tana.it> wrote:=
=C2=A0 To stick with A-R semantics, it should have been named tcp.ip, remote.ip or some such.=C2=A0=C2=A0

=
Note that=C2=A0 RFC8617 section 10.2 (https://tools.ietf.org/html/rfc8617#section-10= .2) does add in an smtp.remote-ip method item.

--Kurt
--0000000000007e5507058f259cc7-- From nobody Fri Aug 2 10:52: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 ABC68120251 for ; Fri, 2 Aug 2019 10:52: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, 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 D8hkng2nfN14 for ; Fri, 2 Aug 2019 10:52:12 -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 3564312024B for ; Fri, 2 Aug 2019 10:52:12 -0700 (PDT) Authentication-Results: mail.aegee.org/x72Hq88o007789; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564768329; i=dkim+MSA-tls@aegee.org; r=y; bh=Lj1oSbPj6QQWv0hk5m6jtu9PeUy4pF2AtE+QEiQ96q0=; h=Subject:From:To:Date:In-Reply-To:References; b=qUViWTtJgNdg6dahv1JtyJ8gzwarp4Uop/ILKN4bf0WuU/URuxNaimSsdthwbzGQz SEt8yCfrgISc1UMI0J/h1avcuzo1tQ4aAkFWOm1ij8t6WsDCnRK6CxqFoBeVlydWBa JF104kGAMskwKMn6xqsVcgUPZIgeqmTFIObNROWyilJoZZc0G9XvJxWK6/yNfAeqdg s+Qv4+naTnNS7dT2KM0QL8AmtS1xFIO6vAi7RHgo1zuQNkM6TTmWV3LUloDlVWjhst wk4jgQ1SLeHte04UvtB8rZ9D5FeBC2rkJ7iT4OxncWjqNi25C910gxorkWTcc8KA7q wyngolWDvT+/G1ZaNwRNZD3UMvBjwXbfyc71ZBNrC25t77/q4nfZdwhpMX69enryjR Oq6T8qaK9wxJK9+2B2/niASDHCs6zXkT2QWbRtO7Z0UPiAwYiQeXYXdRLSBUZQCcDs AFMNsHH1Hg/vVUAaF8os6i//AOsuAznJ0+ZGGKGniwetpiaNeWhseAU1sE4aSAWh1J x1bEdUJbUThZLkqqY+WwpE1ORE3w0RDSImcHsKvo9gjJk4BgF9uBvQ87ngMgj1063S EyXLkhen2JQjE9q5k1cJUf9s0leSe8ud7nIlRkR5NnnE9q6c/akeQsaQ3f3A9wct/v m/ZMxvXDvt/ypGOP61ZAvzJQ= Authentication-Results: mail.aegee.org/x72Hq88o007789; 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 x72Hq88o007789 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 2 Aug 2019 17:52:09 GMT Message-ID: <505750d4fb9c03050508255594c55f4517da3e6d.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: Alessandro Vesely , dmarc@ietf.org Date: Fri, 02 Aug 2019 17:52:08 +0000 In-Reply-To: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] ESC for Failed DMARC Validation 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, 02 Aug 2019 17:52:15 -0000 Hello Alessandro, I mean an enhanced status code, as at https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml . Would you reply to messages failing DMARC with such a code, irrespective of whether the message was accepted or rejected? Are there privacy risks connected with such ESC? Regards Дилян On Fri, 2019-08-02 at 19:18 +0200, Alessandro Vesely wrote: > Hi Dilyan, > > > I'm not clear if you refer to the "DSN" extension (rfc3461). In fact, positive > DSNs contain the A-R header field, and so can inform the sender when a message > is accepted although some of SPF/ DKIM/ DMARC failed. > > I don't send failure reports, as they look plenty of privacy risks. Perhaps > they could be sent to trusted sites only, but that way they'd lose generality. > > It's unfortunate that FR seem to be the only means to tell unwanted failures > from real spam/ phishing successfully blocked by the protocol. Perhaps that > distinction could be added to aggregate reports, even if it's not an exact science. > > > Best > Ale > > > On Fri 02/Aug/2019 18:00:11 +0200 Дилян Палаузов wrote: > > why sites do not sent failure reports? > > > > Will a site, not sending failure report, be willing to use an Enhanced Status Code, to signal, that the DKIM/SPF > > implementations of the receiver and sender disagree? > > > > * * * New Enhanced Status Code for Failed DMARC Validation > > > > Code: X.7.30 > > Assocaited basic status code: Any > > Description: Used as partial substitution to failure reports, when DMARC validation fails. 250 2.7.30 means, that the > > message was delivered, ordinary or as junk, despite failed DMARC validation. 550 5.7.30 is used when the message is > > rejected, because the DMARC validation failed. This status code is only usefull, when the receiving site does not send > > failure reports. > > > > Regards > > Дилян From nobody Fri Aug 2 12:58: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 DF01D1200E9 for ; Fri, 2 Aug 2019 12:58:46 -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 sfahIhM0njDB for ; Fri, 2 Aug 2019 12:58:45 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 9B1AA1200E5 for ; Fri, 2 Aug 2019 12:58:44 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id p17so73953126ljg.1 for ; Fri, 02 Aug 2019 12:58:44 -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=TEDbwlSZzLxK26R3DqYYFmgpFhsFEJNVwiIZB7k6EOI=; b=YxZBBtfo4L80GXe3bk3TWWsWTBXGR0Sa1cDA7YlW+FqUO7PCu+ZnQHSFalqhoMO3eg /MTVopzMIVxaHJ+ICUBHi2MZDiP+SLk6MpBg+OPlVb1K4AcDPRyu2A8TghxdVrZXZHIv Di0kXYtZTH0cWnpWd7Bi/orWcNZ3YfkG6XvHHxIO8N1RgSpB6T/HUpkOILXppRVc1h7c uWLgfuI7wD4DiPkZnfIWFuRbvwe7CKGqXxt0B4nxxX5TxN9yYv0is6T5X0KDRg1emrdA fgw1UPIU5bg7r5mt+4UeNtVBfgW+X/pNqcG8qEyINgml/MMSdr/SUrybWhNJ8fb5vYwo wjnw== 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=TEDbwlSZzLxK26R3DqYYFmgpFhsFEJNVwiIZB7k6EOI=; b=dJT5cOOPHGhSDttyRSfQWKARXlqEuKYI0EEJhgZsoQHLDAUmRsrBszRwZocmIUPTl4 HI2GQUAxJp0Ty5O2dP3K1UMcfXqYwpIa6S4atR34slKxrP447rj4cWoojLaXwxwQ9YGB 6SBcGJdBIugS67g2Myi2Ba6VvxT47nT5uTIHHLPa5NvlmFN9ce4ci6jS720quANrUDO9 y+x9XRoiedASp2OI20VZTwMtR8F9hxRuY6aw0NCAhziqYPpeVD8OZL6tyf7NyX9l/yzv zAE4oDTKIaQGiV5lsOXEJQIOYO7EEf7RWT4T24CVUoNx2cZdDzXkKIQEwgqy3xONhVnJ aOaA== X-Gm-Message-State: APjAAAW1nvXks5i7erHFC7CvfjrZPrLlKQ8IYI1IqFxSdVtvQpApKy6i wmEQcUHTeSaSpf/0PAzez56H8v0RxdAHZfVBRy0aBTbm X-Google-Smtp-Source: APXvYqyC2lRv/71+yKhbcJFT9N41sgjH5it5QBbMqHmlVsiRLZtR+0zrGsKeXC3Kp2y3AwGcIeApfF2biyz2upd7ZI8= X-Received: by 2002:a2e:9a19:: with SMTP id o25mr72862611lji.63.1564775922650; Fri, 02 Aug 2019 12:58:42 -0700 (PDT) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Fri, 2 Aug 2019 12:58:30 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000005daba058f27c916" Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 19:58:47 -0000 --00000000000005daba058f27c916 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: > Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, > does not contain the term "policy". > Wow. I'm amazed I got away with that. But it is clear from the things in the registry that that's how you do it. My recollection is that reporting the > client IP is immaterial, as for SPF. The term policy.iprev is certainly > misleading, since the value is not related to a locally-defined policy, > and is > not a reversed ip. To stick with A-R semantics, it should have been named > tcp.ip, remote.ip or some such. If a property warrants deprecation, it's > policy.iprev. > The choice of "policy" for "iprev" is rooted in history, because the earlier versions of the document (as you well know) demanded that the things being reported had something to do with the message itself. "iprev" was an exception the community chose to allow. It pre-dated RFC5782 which introduced DNSxLs formally. For guidance here, I would rely on anecdotes of implementation. Has anyone implemented something that attaches "iprev" results? Now for dnswl. Knowing which zone was queried is substantial in order to > interpret policy.ip, because there is no standard format. Yet, an > implementation could just throw a DNS query to a given local IP, instead > of a > FQDN to the default DNS server. In that case, one would have, for example: > > dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2 > > In that case one can hardly tell which is which. A meaningful ptype helps. > Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"? I would expect it to have that knowledge, not downstream things. Again, I don't know what the value of "dnswl=pass" is if the thing attaching it doesn't even know how to interpret the result it got. -MSK --00000000000005daba058f27c916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 2, 2019 at 3:00 AM Alessandro= Vesely <vesely@tana.it> wrote:=
Let me note that Section 3 of rfc8601, /The "iprev" A= uthentication Method/,
does not contain the term "policy".

Wow.=C2=A0 I'm amazed I got away with that.

=
But it is clear from the things in the registry that that's how yo= u do it.

My recollection is that reporting the
client IP is immaterial, as for SPF.=C2=A0 The term policy.iprev is certain= ly
misleading, since the value is not related to a locally-defined policy, and= is
not a reversed ip.=C2=A0 To stick with A-R semantics, it should have been n= amed
tcp.ip, remote.ip or some such.=C2=A0 If a property warrants deprecation, i= t's
policy.iprev.

The choice of "polic= y" for "iprev" is rooted in history, because the earlier ver= sions of the document (as you well know) demanded that the things being rep= orted had something to do with the message itself.=C2=A0 "iprev" = was an exception the community chose to allow.=C2=A0 It pre-dated RFC5782 w= hich introduced DNSxLs formally.

For guidance here= , I would rely on anecdotes of implementation.=C2=A0 Has anyone implemented= something that attaches "iprev" results?

Now for dnswl.=C2=A0 Knowing which zone was queried is substantial in order= to
interpret policy.ip, because there is no standard format.=C2=A0 Yet, an
implementation could just throw a DNS query to a given local IP, instead of= a
FQDN to the default DNS server.=C2=A0 In that case, one would have, for exa= mple:

=C2=A0 =C2=A0dnswl=3Dpass policy.ip=3D127.0.9.2 policy.zone=3D127.0.0.2

In that case one can hardly tell which is which.=C2=A0 A meaningful ptype h= elps.

Why would the thing attaching "dn= swl=3Dpass" not also interpret "policy.ip"?=C2=A0 I would ex= pect it to have that knowledge, not downstream things.=C2=A0 Again, I don&#= 39;t know what the value of "dnswl=3Dpass" is if the thing attach= ing it doesn't even know how to interpret the result it got.
<= div class=3D"gmail_quote">
-MSK
--00000000000005daba058f27c916-- From nobody Fri Aug 2 13:01:59 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 D584B1200E9 for ; Fri, 2 Aug 2019 13:01:56 -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 pvEVtNhxcaDs for ; Fri, 2 Aug 2019 13:01:55 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE77512014F for ; Fri, 2 Aug 2019 13:01:54 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id m8so40346054lji.7 for ; Fri, 02 Aug 2019 13:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HA6pR4NOItNjcQ56LlYvLUhHueZUYnoNoI6IfpDUKbs=; b=XPx2tQoDS5H8bFCUZQRrZjlXuyGE4h0NXcVZfw3TL5rxhyt1mcYACRQa4rQB3yjUQG 55pvkw9TcoW8vR9RR/MS+DfDsECYDxI9hr3n1iMOXFwK38pn7xbbNikuJ4yXnXoVjaR+ +97isf2xxSQHlNB0/e8NilSQ82jhlNqyC/8bu90AQdZuI56CVZrmALdeei9EiX8kck0d yhNkRknnoEEa2Nc+ws0fxZ06q92cb0SxRMAVeE2ZTPcdN7Y5Z/qw8napURNIZoLTNfYu FXk+ouz4rjF4VhcGwX1OPUojMIEFK6d1WfIL9oRVpRI12izfAy+506PL1bG1gM64a65O uscw== 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=HA6pR4NOItNjcQ56LlYvLUhHueZUYnoNoI6IfpDUKbs=; b=lq4+W6tvE8TMBp/YVbVLd50mT/TKTR2Qf9mlrgwJgB6//9pPx0EQFc33ono/OAe692 u7xZm0x8zDbq5QoFMYtP3nCRuMdQLZiEfJSfsHiyQP2g57UFEQhwG0ARoQqRtStiQ2Nt XILXbg6+DhF2G56bg+QYhlCuEd2gkDaJk46WgNaYC10JDfdfHq/y4atn9tbXgVtmEg2X 5fB/UC5UpiuJ0nXlepJRD/fdB6dJ9rrC0xDrIXRUVhW02QzjVwjy1D/hBqahWdQxh8TP QfdYlVzXpLhz+v/UKvJ1JRxxYHxRlS1+DWbOd8qLUHvAUYYvfCgjCTlkjwr/sU93NI5F cHyg== X-Gm-Message-State: APjAAAW3o2gUwhTeMevt320Y5gB6nWzNBV1UCBobGiG2NZX7eDxPRm1l jDuUZqM/e4rPe5QwCsse47PxrXdYkpbjXhcweMdUDQ2x3Gc= X-Google-Smtp-Source: APXvYqz0YCKqXXWi2vD0SugWLFdLk387SIAviXiQMtfrk7xL4wcGIY9E/ql8N7qtWugnL3eLduTJE3UyrDqlEfv7i9g= X-Received: by 2002:a2e:988b:: with SMTP id b11mr5553669ljj.110.1564776113258; Fri, 02 Aug 2019 13:01:53 -0700 (PDT) MIME-Version: 1.0 References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> In-Reply-To: <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> From: "Murray S. Kucherawy" Date: Fri, 2 Aug 2019 13:01:41 -0700 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000062452c058f27d4ab" Archived-At: Subject: Re: [dmarc-ietf] ESC for Failed DMARC Validation 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, 02 Aug 2019 20:01:57 -0000 --00000000000062452c058f27d4ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 2, 2019 at 10:52 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: > I mean an enhanced status code, as at > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced= -status-codes.xhtml > . > RFC7372 registered some for exactly this purpose (though not specific to DMARC). Its Security Considerations section talks about the privacy risks. I don't know if they're actually in use. -MSK --00000000000062452c058f27d4ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 2, 2019 at 10:52 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 <= dilyan.palauzov@aegee.org&= gt; wrote:
I mean an enhanced status code, as at
https://= www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-co= des.xhtml .

RFC7372 registered some for = exactly this purpose (though not specific to DMARC).=C2=A0 Its Security Con= siderations section talks about the privacy risks.

I don't know if they&#= 39;re actually in use.

-MSK
--00000000000062452c058f27d4ab-- From nobody Fri Aug 2 13:19: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 7116C120822 for ; Fri, 2 Aug 2019 13:19:35 -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 fjjLpIlbsKLB for ; Fri, 2 Aug 2019 13:19:32 -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 6AF7012080D for ; Fri, 2 Aug 2019 13:19:30 -0700 (PDT) Authentication-Results: mail.aegee.org/x72KJQBX030953; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564777167; i=dkim+MSA-tls@aegee.org; r=y; bh=/lDEnu2LhVmQu5SQzr1X6BDsMavlK05y2XddwAu2BKI=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=B4WnfOSKy1zf4VV0Cn6/INese/xMkPWBQuqNJUi6zxVOMYTMioU29kRCvDABgLYpo ITAhKDWj5MOyDzgEmNsZvba8C3o+AAEA2gtNtXEy45pInijruh4UKSrY+XTNv5925W fpUsjYn3hBTlJaTm2c8UUJggCuAP1Yr1tBibI4Xc7CwmVbvChAhto3ltrjHBFeRC+e SVvPlb6EffuruXC65BbXkD8T8e6CmCm/OFGuP6/sOvbzA6Qgb8GlqfJU322pAP2QEF NNAgsIJ7XMWyq58HPxUNInnwBdP7HMXon3MV66z3wBHBV8A5JPNnQ8e1k3qwJpBcQX a3XywS4xOqT4Tbjvp9GonBEQxg8SrmKeNYpLVzW/P0tXKQMcpjdvEnmx8Y7JgbMquP 98yrY/8yZVzDINdGY2AWdV4BsvdASDxyff936hT9asg2oBu8tn1QCp77dhg+WtzZ9D /PzZYjp01cweL2UhV5+bb+pkU+seew0kPt+myW9zmaO6yUcwRbx1elkj5V9yLfz8bk MpjBq5Hhd6YXcFG6hiijAJdJhO4Uqqg/5P1o58swbkRWUCCIokk2QZeafGa6sdcSPQ uwgK8HNV5Wuk0mVjOf45fN/vpaOXKTWQXl26nd3XSnb9peNJM8n6j+5G4Yb7PBiU5H 1+NbxPiEqGx5zozuqy4La9ek= Authentication-Results: mail.aegee.org/x72KJQBX030953; 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 x72KJQBX030953 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 2 Aug 2019 20:19:27 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: "Murray S. Kucherawy" Cc: IETF DMARC WG , Alessandro Vesely Date: Fri, 02 Aug 2019 20:19:26 +0000 In-Reply-To: References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] ESC for Failed DMARC Validation 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, 02 Aug 2019 20:19:40 -0000 Hello Murray, ESC X.7.20, X.7.21 and X.7.22 are glued to return code 550, while I propose an ESC, that works also with 250. Apart from this, X.7.20 and X.7.21 cannot be used instead of the proposed X.7.30: If a site sees a valid DKIM signature, and previous experience with the domain signing DKIM leads to increased trust in this domain, then the signature is acceptable, but it does not have to align with the From: address. With X.7.22: Description: This status code is returned when a message contains one or more passing DKIM signatures, but none are acceptable because none have an identifier(s) that matches the author address(es) found in the From header field. This is a special case of X.7.21. (This violates the advice of Section 6.1 of RFC 6376.) If “none have an identifier that matches the author address found in the From header field” means, that the DKIM part of DMARC fails, then this ESC can be recommended by the DMARC specification to signal to the sender, that the DKIM implementations of sender and receiver disagree, as a light substitute to the failure reports. Greetings Дилян On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote: > On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов wrote: > > I mean an enhanced status code, as at > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml . > > RFC7372 registered some for exactly this purpose (though not specific to DMARC). Its Security Considerations section talks about the privacy risks. > > I don't know if they're actually in use. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Aug 2 13:55: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 8A6A312013D for ; Fri, 2 Aug 2019 13:55:15 -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 5SHxb2IZw3iX for ; Fri, 2 Aug 2019 13:55:13 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 DBD25120134 for ; Fri, 2 Aug 2019 13:55:12 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id q26so53870986lfc.3 for ; Fri, 02 Aug 2019 13:55:12 -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=BW6mFo4gT3m/VPTbAVNrTj1EjnVyk7VEjRH9sAv8qNw=; b=gvZnbeNMnYHMvLC7ginsIdn6WPvay76oAd0Nbpd3U0FLiEmc3fXykQDoXjFhD1UfLF OaVcysTSkDlIHYzYJbX+YdgnPwE3y+TDIovcp4daNmrAf28bDYqF/BtzkCPxlT6pPDf6 SqlO/FEfOEZe22Lqfo4Glx9cTKvpLHG6aa38rhrM+ra41C34EPNaEDSfbr5dV6cRcT9Q mcFEDfdYxo/sSt8t5VGb1muSNazSxdaYIlu4CCL88nZncQ4h3WTZpEeNJVEWMSusS8J0 VN0M/kEKGs8bsvAjcnnEKWgHc58sibTAUuvn7iGmg/DSW6O2M2yg22//egeub4pOESr0 X1JQ== 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=BW6mFo4gT3m/VPTbAVNrTj1EjnVyk7VEjRH9sAv8qNw=; b=GGtNtluqTnQlQmVf3JT4vV8nzMiF5QzvdDant12J/BQ4uutHFuS58hVy9R6p767LE3 3dfTrXbq00tAMSX4oER7BNO6kxhpL8ltOcZjo5d8UTeQUpKTXY9KuJp7JuzwmoiGwnjQ 4vRNzbNRBWvLltAhj9d18OMYuYmFU9jozvgSD2CRdJ+DA1gwKb0DMvNKXegr0nuLlSSd dclGTAx1dKAIJSO+H4Psg1Kgz2qSd59cW1/EgQj4c7FODozC7VLyN6SGtCRmEKt+C589 6R9+mzB1HYZkdu/4aSoh/ENAksv7KoiNJj3qX2mCdcmL6AVKVznARqCW9qJ98gLuHTrO MVAg== X-Gm-Message-State: APjAAAWoV/7q14otFtfq7VApMfIL/GORwontKE7F1W0iZF2A3q9Y2bG4 WacAcw0jNzGkm3C9qxHMjdJOTURqQLBEEYhCJSI= X-Google-Smtp-Source: APXvYqxqRH3qYKi8vNCTvlI9COcjW1+Yr/TsrTBsPphRKWALV42aFsmzbsCn5Yqeq3xiduN0SOxZPu3s71o6lXKTXM0= X-Received: by 2002:a19:6e4d:: with SMTP id q13mr23999759lfk.6.1564779311009; Fri, 02 Aug 2019 13:55:11 -0700 (PDT) MIME-Version: 1.0 References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> In-Reply-To: From: "Murray S. Kucherawy" Date: Fri, 2 Aug 2019 13:54:58 -0700 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: IETF DMARC WG , Alessandro Vesely Content-Type: multipart/alternative; boundary="000000000000fc169d058f289288" Archived-At: Subject: Re: [dmarc-ietf] ESC for Failed DMARC Validation 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, 02 Aug 2019 20:55:16 -0000 --000000000000fc169d058f289288 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The wording you're using seems inconsistent to me. Specifically, you're saying that x.7.30 means one thing when attached to a 200-series reply, but the opposite when attached to a 500-series reply. I would prefer to see two separate codes if you're going to do this. But the bigger question is implementation. Who would make use of this, either as a sender or a receiver? -MSK On Fri, Aug 2, 2019 at 1:19 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 Murray, > > ESC X.7.20, X.7.21 and X.7.22 are glued to return code 550, while I > propose an ESC, that works also with 250. > > Apart from this, X.7.20 and X.7.21 cannot be used instead of the proposed > X.7.30: > > If a site sees a valid DKIM signature, and previous experience with the > domain signing DKIM leads to increased trust in > this domain, then the signature is acceptable, but it does not have to > align with the From: address. > > With X.7.22: > > Description: This status code is returned when a message > contains one or more passing DKIM > signatures, but none are acceptable because > none have an identifier(s) > that matches the author address(es) found in > the From header field. This is a special > case of X.7.21. (This violates the advice > of Section 6.1 of RFC 6376.) > > If =E2=80=9Cnone have an identifier that matches the author address found= in the > From header field=E2=80=9D means, that the DKIM part of > DMARC fails, then this ESC can be recommended by the DMARC specification > to signal to the sender, that the DKIM > implementations of sender and receiver disagree, as a light substitute to > the failure reports. > > Greetings > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > > On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote: > > On Fri, Aug 2, 2019 at 10:52 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 < > dilyan.palauzov@aegee.org> wrote: > > > I mean an enhanced status code, as at > > > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced= -status-codes.xhtml > . > > > > RFC7372 registered some for exactly this purpose (though not specific t= o > DMARC). Its Security Considerations section talks about the privacy risk= s. > > > > I don't know if they're actually in use. > > > > -MSK > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > --000000000000fc169d058f289288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The wording you're using seems inconsistent to me= .=C2=A0 Specifically, you're saying that x.7.30 means one thing when at= tached to a 200-series reply, but the opposite when attached to a 500-serie= s reply.=C2=A0 I would prefer to see two separate codes if you're going= to do this.

But the bigger question is implementation.= =C2=A0 Who would make use of this, either as a sender or a receiver?
<= div>
-MSK

On Fri, Aug 2, 2019 at 1:19 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 <= dilyan.palauzov@aegee.org&= gt; wrote:
Hello= Murray,

ESC X.7.20, X.7.21 and X.7.22 are glued to return code 550, while I propose= an ESC, that works also with 250.

Apart from this, X.7.20 and X.7.21 cannot be used instead of the proposed X= .7.30:

If a site sees a valid DKIM signature, and previous experience with the dom= ain signing DKIM leads to increased trust in
this domain, then the signature is acceptable, but it does not have to alig= n with the From: address.

With X.7.22:

=C2=A0 =C2=A0 =C2=A0 Description:=C2=A0 =C2=A0 =C2=A0 =C2=A0 This status co= de is returned when a message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 contains one or more passing DKIM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 signatures, but none are acceptable because
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 none have an identifier(s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 that matches the author address(es) found in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 the From header field.=C2=A0 This is a special
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 case of X.7.21. (This violates the advice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 of Section 6.1 of RFC 6376.)

If =E2=80=9Cnone have an identifier that matches the author address found i= n the From header field=E2=80=9D means, that the DKIM part of
DMARC fails, then this ESC can be recommended by the DMARC specification to= signal to the sender, that the DKIM
implementations of sender and receiver disagree, as a light substitute to t= he failure reports.

Greetings
=C2=A0 =D0=94=D0=B8=D0=BB=D1=8F=D0=BD


On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote:
> On Fri, Aug 2, 2019 at 10:52 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 <dilyan.palauzov@aegee.org> wrote:=
> > I mean an enhanced status code, as at
> > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced= -status-codes.xhtml .
>
> RFC7372 registered some for exactly this purpose (though not specific = to DMARC).=C2=A0 Its Security Considerations section talks about the privac= y risks.
>
> I don't know if they're actually in use.
>
> -MSK
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org=
> https://www.ietf.org/mailman/listinfo/dmarc

--000000000000fc169d058f289288-- From nobody Fri Aug 2 14:06:35 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1B612013B for ; Fri, 2 Aug 2019 14:06:33 -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, RCVD_IN_DNSWL_LOW=-0.7, 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=sonnection.nl 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 RZfzkpAofl_Z for ; Fri, 2 Aug 2019 14:06:31 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2441200E9 for ; Fri, 2 Aug 2019 14:06:31 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 460fps5Chzz2qF1D; Fri, 2 Aug 2019 23:06:29 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx10.mailtransaction.com 460fps5Chzz2qF1D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1564779989; bh=8TVVJbq5obKWSHQBpSQqtfzq1k9QKz8DibiPHEslsLs=; h=Subject:To:From:Message-ID:Date:From; b=KgK4vYs83MCPRSrQqo//zxYETmgiQ+7exT5HNdvj/o7jX4rAHpzqOHeQKqTiRA2T4 awmLToEGO6mM3yFGiGipDcyRcYu7oJ2QsH388WATt5/eZa1iHsNeOf6uHmMJNeR6r9 +G14lBTA34uQfhYXkxSGxPjOG1gZS0rI9dOs04Y8= Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 460fpr5t3Lz1tp3T; Fri, 2 Aug 2019 23:06:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 8E6D8422340; Fri, 2 Aug 2019 23:06:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YkpV99pQoCXH; Fri, 2 Aug 2019 23:06:28 +0200 (CEST) Received: from [192.168.40.49] (cat.sonnection.nl [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id 75F7142233F; Fri, 2 Aug 2019 23:06:28 +0200 (CEST) To: "Murray S. Kucherawy" , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: IETF DMARC WG , Alessandro Vesely References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: <9ffdbe9e-7720-0a39-876e-7bfbdd0b9366@sonnection.nl> Date: Fri, 2 Aug 2019 23:06:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] ESC for Failed DMARC Validation 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, 02 Aug 2019 21:06:33 -0000 On 02-08-19 22:54, Murray S. Kucherawy wrote: > The wording you're using seems inconsistent to me.. Specifically,=20 > you're saying that x.7.30 means one thing when attached to a=20 > 200-series reply, but the opposite when attached to a 500-series=20 > reply.=C2=A0 I would prefer to see two separate codes if you're going t= o do=20 > this. > > But the bigger question is implementation.=C2=A0 Who would make use of=20 > this, either as a sender or a receiver? a receiver could assist a sender in adjusting its egress mail process=20 without the need for the receiver to collect a lot of DMARC reports and=20 analyse them. A sender could use it to improve its outbound mailflow. I=20 doubt however whether anyone will implement this as it assists possible=20 adversaries as well... /rolf From nobody Fri Aug 2 14:27: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 32945120147 for ; Fri, 2 Aug 2019 14:27:54 -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 jjrs7TMdkrqc for ; Fri, 2 Aug 2019 14:27: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 CC5F312013B for ; Fri, 2 Aug 2019 14:27:51 -0700 (PDT) Authentication-Results: mail.aegee.org/x72LRmtZ007157; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564781269; i=dkim+MSA-tls@aegee.org; r=y; bh=xJHbCuvpQXCH+e+8FqKXT1ySBM6jRhNPJ/DKchTGi80=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=FBaEFEr1e4m2zbMAopvzhsT33Inbm1kB77p3DQ3wtjhNui/3dtP9tnVcMfUZ14O04 ZIZO3/F2s6L/4y1zPUue/e3sxPwnFmaaFxtmCUQOhWs1WnrcV711DhapQsRTWMmzO9 MXpccaXpOXOhtip+68sRJBA11MQUke67mqrfqWmI1ImBSx5vKuapMCfhkyY4/vWDiM NjkjKTX3T6qtoeuwlzu6T/aY1LE+ffFNXmgbhIhflEIeO2W2jtA6yMicjknc+DEkSV UyJvN6bJKgfyFjIZi55i+LnZp0gYZUL5ndFmKuunYJ7Pgd9vTBR65SdvEiBcjm5Q9f KA7z2y8AyHrL/MAxaWHAMoYhS6LlQn5ox0RWHyH9IijIV0mvWd9Um2LQ5fGr3mXicW DbxBOLR4GK8uhA+Qtm5v5piPCe0ogYnIBxY1nE+OivW4qVbQkQY84TbRn2A7W+YGQC 9o7N0Ivgf1ozlkMHBZimFXKebH+mebJPLtJvOUsCODsvmJJjv4JSbKMoJVaKTeOIsw KSPeveMhuZolp7dFz5dPpfgVMfouKF8f32wA5JM32KelzsukqWanFo0SOK4ZYVDjA4 WQOIKolHPE78mGuLa0VcOgN8HVjGEec+2NN0+texrFagNN7rNkKIunk87BYL9fO6Im CUoqGFPeb0wpvsx21H0r8vMU= Authentication-Results: mail.aegee.org/x72LRmtZ007157; 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 x72LRmtZ007157 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 2 Aug 2019 21:27:48 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: "Rolf E. Sonneveld" , "Murray S. Kucherawy" Cc: IETF DMARC WG , Alessandro Vesely Date: Fri, 02 Aug 2019 21:27:48 +0000 In-Reply-To: <9ffdbe9e-7720-0a39-876e-7bfbdd0b9366@sonnection.nl> References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> <9ffdbe9e-7720-0a39-876e-7bfbdd0b9366@sonnection.nl> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] ESC for Failed DMARC Validation 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, 02 Aug 2019 21:27:54 -0000 Hello, these are already now two ESC: 2.7.30 and 5.7.30. X.7.30 means in both cases, that DMARC validation failed. For a domain with policy p=reject; pct=0 the mail is delivered (250 2.7.30), despite failed DMARCр and for a domain with p=reject; pct=100 when DMARC failed and the mail is rejected (550 5.7.30). Please propose a different wording, I do not see a contradiction in my wording. Who will use it? I asked, why failure reports are not sent by some sites, and would the ones, who do not send failure reports, use the X.7.30 code. (Thus, if for failure reports there are concerns, while for ESC X.7.30 there are no concerns). I expect that at least parties who want to fix their DMARC/DKIM implementation will use it. The aggregate reports provide hints, that the DKIM implementation does not work. This ESC is not meant as a shortcut to collecting a lot of reports and analyzing them, it is a mean to act when no reports are sent. Regards Дилян On Fri, 2019-08-02 at 23:06 +0200, Rolf E. Sonneveld wrote: > On 02-08-19 22:54, Murray S. Kucherawy wrote: > > The wording you're using seems inconsistent to me.. Specifically, > > you're saying that x.7.30 means one thing when attached to a > > 200-series reply, but the opposite when attached to a 500-series > > reply. I would prefer to see two separate codes if you're going to do > > this. > > > > But the bigger question is implementation. Who would make use of > > this, either as a sender or a receiver? > > a receiver could assist a sender in adjusting its egress mail process > without the need for the receiver to collect a lot of DMARC reports and > analyse them. A sender could use it to improve its outbound mailflow. I > doubt however whether anyone will implement this as it assists possible > adversaries as well... > > /rolf > From nobody Fri Aug 2 14:41:12 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35F41200E9 for ; Fri, 2 Aug 2019 14:41:10 -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 giaAiHaCyd71 for ; Fri, 2 Aug 2019 14:41:09 -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 1667D120059 for ; Fri, 2 Aug 2019 14:41:08 -0700 (PDT) Authentication-Results: mail.aegee.org/x72Lf4NZ008709; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564782066; i=dkim+MSA-tls@aegee.org; r=y; bh=4RVCc8zQRi5gTHndbQ4+/PXVE0+krXAwQ0Q0zNABbZo=; h=Subject:From:To:Date; b=kb+VPnZ4eht05LqreZw0XlnDcXbA3Tt5OtkeMf64LCp8zOFVBNSvnqqdY1Dr91/RC nnqA4/NZ91wkfqOLc0QVEkRic+Bv3p9y7wefM4YuMZx6ghqJXZ+qeXRFUKsOyoy02R TWMIg07cpUb0Q5guw0UgneRoqSYxEftHUZFSkbrh5OIBe7IGlYZ4q/PI528GsATiW8 cm3eEvGZCaZyCmHkiOX0bMmUDHBDSKjCB08lh1T+59vgde16XKe4cFalOLVNaD7hrF zx6rhB45DeCAwqdeAMtfvyMXP+ruHV0oyJnoKE+BYJT4P62SMT6MSRRc1/P2+pa3XX bRh52DSDYtFKGU1E5MWZwc1K96g0UnFzfGz6+57Q+KXXSCn2K8ykoVXDbcPVuaSOth BT9ooYW2opZygVVDIEafr2zzMSihstuozIUWZ8QCOAA31eBDH41TMdmLzo8v+nqlQk MAKqu+9l5eI2dT4jCofSSxAe3TY1aejK9WpfRDdi0buGAkj888eK3mf4uDIFfSSI16 ZVIK6w17w1IgZHD0FTDXThHNB16xl+TvngzSOlsC5vToN86ZnxhJsohOQQEc/pok+f 1iQQHYaeDuSAyvpHl7f/edKtL6cQ1em5axUByXzoZdw/MCtoy4yFezgU762eM2aVMV m7wiwyVjtcXukLCJLfkei2us= Authentication-Results: mail.aegee.org/x72Lf4NZ008709; 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 x72Lf4NZ008709 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 2 Aug 2019 21:41:05 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 Date: Fri, 02 Aug 2019 21:41:04 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] Concerns for not Sending a Failure 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, 02 Aug 2019 21:41:11 -0000 Hello, I just thougth once again on this. Some of the senders of aggregate reports offer free mailboxes. Aggregate reports show that emails from a host to a provider of free mailboxes sometimes do not validate DMARC. The one provider sending emails opens a free mailbox on the receiver and then sends a secret copy of each, otherwise ordinary delivered email, to that special mailbox. Then the mails from that mailbox are downloaded, and the A-R header is checked. By this way the sender finds out, which messages exactly have failed DMARC validation. At the end the same information is obtained, that can be obtained by exchanging a failure report: which messages have failed. Has somebody done this? Why does it have to be that complicated? Regards Дилян From nobody Fri Aug 2 15:02: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 91C99120128 for ; Fri, 2 Aug 2019 15:02:20 -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 fuIEqdXSXwvz for ; Fri, 2 Aug 2019 15:02:19 -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 0777712004F for ; Fri, 2 Aug 2019 15:02:18 -0700 (PDT) Authentication-Results: mail.aegee.org/x72M2FTT012626; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564783336; i=dkim+MSA-tls@aegee.org; r=y; bh=m/QFd7Iq+doPOYr19Z78rZHu0ER/pPj0g2JRVztYVnI=; h=Subject:From:To:Date; b=C9YUeIdTXM+JgXRpSmHQ3Gm0+alCAp76hHqtroKsIdFplFoU1d3ltKu8g1XOj44G8 lIjSO7tIow76jEiL/byyMJI1ESLqUrfUbEv2CKoLYe0rv375HeKui75dGDgmnb3OxQ CCeLoSAi++vpDaX3ySBbh6Jgu8KIaF8+9vgg1IYn1pHhvlUvkba7Iqw6W8YGFnX54O 1QusQRJLLxZfbeHh6etrYJQcO0LdoHaUPGj8+fRYajMQjXENwEpIKQago235yd2UJu 8v7Jd6mO2GPCApRxmeqXi2mlJfjSo+6RclO3zUJbtmIKatTUvQvgDqQ7Srg/X13Ycw IK5VYoBFaKXuLUKCgkHIgwm56OlUjukH37BgO1gM32OTR4FHo6cgd6rF3wbjKchRoC t2NTq1BAPArzWhbTB6a8up0iHe1NbAmRwVoLgJL3qIiPiCfQHsZB9aNvRajXvE3Z+n zTEMGwyCTyvu/hqkiPO01+xQE0OPpN4RTHjFHZYGpxDgPhLTCNrSTirvTdLpI663Ph penRhuIFuPPZWx0zzTUhv7Lo/exDKBbsHCo2PGshWYlwtYQ6Jg6IK2hUJ9v8WuwbbZ r+D5ZkKXZpRi6cZWqfHA/t7wy7q5SyK1g+z9PechajWAJla0n/Wmg76j/cA+nZOUv6 mo6fltetW+vb1VEn2FHjsHNc= Authentication-Results: mail.aegee.org/x72M2FTT012626; 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 x72M2FTT012626 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 2 Aug 2019 22:02:16 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 Date: Fri, 02 Aug 2019 22:02:15 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] New proposed wording for p=quarantiine 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, 02 Aug 2019 22:02:21 -0000 Current wording for p=quarantine quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". Amendment to the wording for p=quarantine: … or reject at SMTP level. The Domain Owner wishes in addition, that the sender of messages failing DMARC are notified about the suspicious handling with an appropriate rejection message. Senders not willing to be notified that their message is suspicious, shall use the NOTIFY=NEVER service extension. In the past, Domain Owner could express as wish either to reject or to quarantine. Considering that from the options: only reject; only qurantine; and quarantine, while notifying the sender about the suspicious handling of the message; nobody will choose only to quarantine, the interpretation of what the Domain Owner wishes by publishing quarantine was changed to include the rejection component. From nobody Fri Aug 2 15:31: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 9BE86120077 for ; Fri, 2 Aug 2019 15:31: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=Q1BXywZZ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Bg6WBExN 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 ZWNN-MaRyzay for ; Fri, 2 Aug 2019 15:31:16 -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 27447120059 for ; Fri, 2 Aug 2019 15:31:16 -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 161E7F8049F for ; Fri, 2 Aug 2019 18:30:45 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564785044; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=psqrTw8Tk2i1UuuBOuOTjQtnrRVQyMQ43kykHph4O8Y=; b=Q1BXywZZqreGbSY/cJg4cI4Li5UHMehBYeEr3NCjElvzCC5e0hAymdqU Tc5JUFYLALu5vt1BNZjRP6RahwK+Dw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564785044; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=psqrTw8Tk2i1UuuBOuOTjQtnrRVQyMQ43kykHph4O8Y=; b=Bg6WBExN76GzXDAoQlpmzTe4SG/shVJR+fYO92fL5sK2vijdWCiSFbVF qh2dq9xitKWOfS6aMY1n1aeo6d39U/eHh3abHRTrhtGSbhkD4xoZeOOHFA L5ul+dPGMyh1SyPpgZNchgNyj0WZX4no38Sgj+1P9xJV+Zgt+aAQwCA+zt AqmUqioxK+irORa95dAqMygZkonbYO//Z3DjRfVGZhD2i6QlS3vfc5egaW pMKoqsFkR5RAFB/CKoO3Y39dabELo3GbbKrVg1cA4QOa4aixuptKkZrn1+ d+BsIbBdvH5/mMx4sQi/ZtZNSyuTWSwrqBQs/01wDDwQIwswQdRsEQ== 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 B4834F80096 for ; Fri, 2 Aug 2019 18:30:44 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 02 Aug 2019 18:30:43 -0400 Message-ID: <6247286.Dd9LSJjpfE@l5580> In-Reply-To: References: <4195597.6UoUMpgHb9@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 02 Aug 2019 22:31:19 -0000 Is silence concurrence? Comments inline. Please let me know how to proceed on updating the draft. I'd appreciate anyone else's feedback too. Scott K On Wednesday, July 31, 2019 8:28:17 PM EDT Murray S. Kucherawy wrote: > Thanks for this, much better. Some additional feedback. > > Please note (everyone) that I'm offering these as clarifying contributions > to text; I'm not prescribing or proscribing anything. If the text I'm > proposing isn't worthy of consensus, please speak up. > > On Sat, Jul 27, 2019 at 1:45 PM Scott Kitterman > > wrote: > > I updated the paragraph to start: > > DMARC (Domain-based Message Authentication, Reporting, and > > Conformance) is a scalable mechanism by which a mail-originating > > organization can express domain-level policies and preferences for > > message validation, disposition, and reporting, that a mail-receiving > > organization can use to improve mail handling. DMARC policies can be > > applied to individual domains or to all domains within an > > organization. The design of DMARC precludes grouping policies for > > domains based on policy published above the organizational level, > > such as TLDs (Top Level Domains). > > > > Does that clear those comments up? > > That last sentence still puzzles me, and I think it's the term "grouping" > that gives me trouble. > > How's this? > > DMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. The design of DMARC > presumes that domain names represent either nodes in the tree below > which registrations occur, or nodes where registrations have occurred; > it does not permit a domain name to have both of these properties > simultaneously. Since its deployment in 2015, use of DMARC has shown > a clear need for the ability to express policy for these domains as > well. > > Domains at which registrations can occur are referred to as Public > Suffix Domains (PSDs). This document describes an extension to DMARC > to enable DMARC functionality for PSDs. > > This document also seeks to address implementations that consider a > domain > on the Public Suffix List (PSL) to be ineligible for DMARC enforcement. > > > If we like this, I suggest it or language like it can also be used to > rework the first paragraph of the Introduction section in -05. To > import DMARC definitions into the introduction, you could say that > DMARC presumes that a domain is either on the PSL or is an OD, and > never both,. I think this is generally fine, but it should be public suffix list (not capitalized) as that's what's used in the main body of RFC 7489. Appendix A. 6.1 uses the PSL as an example, but it's only one possible source of such data. What would you (you = anyone) suggest for the introduction rewrite? > > > As an example, imagine a country code TLD (ccTLD) which has public > > > subdomains for government and commercial use (.gov.example and > > > .com.example). Within the .gov.example public suffix, use of DMARC > > > [RFC7489] has been mandated and .gov.example has published its own > > > DMARC [RFC7489] record: > > > > > > "v=DMARC1;p=reject;rua=mailto:dmarc@dmarc.service.gov.example" > > > > > > Can we add spaces after the semicolons? I know this is legal format > > > but it would be more readable. > > > > Changed. > > Thanks. Now for the text right before the example; I suggest: > > As an example, ... Suppose there exists a registered domain > "tax.gov.example" that is responsible for taxation in this imagined > country. However, by exploiting the typically unauthenticated nature of > email, there are regular malicious campaigns to impersonate this > organization that use similar-looking ("cousin") domains such as > "t4x.gov.example". These domains are not registered. Within the > ".gov.example" public suffix, use of DMARC has been mandated, so > "gov.example" publishes the following DMARC record: > > ... > > Defensively registering all variants of "tax" is obviously not a scalable > strategy. The intent of this specification, therefore, is to enhance the > DMARC algorithm by enabling an agent receiving such a message to be able to > determine that a relevant policy is present at "gov.example", which is > precluded by the current DMARC algorithm. Looks good to me. Unless someone else suggests differently (soon), I'll do that. > > > There are two types of Public Suffix Operators (PSOs) for which this > > > extension would be useful and appropriate: > > > > > > o Branded PSDs (e.g., ".google"): These domains are effectively > > > > > > Organizational Domains as discussed in DMARC [RFC7489]. They > > > control all subdomains of the tree. These are effectively private > > > domains, but listed in the Public Suffix List. They are treated > > > as Public for DMARC [RFC7489] purposes. They require the same > > > protections as DMARC [RFC7489] Organizational Domains, but are > > > currently excluded. > > > > > > How are they current excluded? Is this because they're on the PSL, so > > > DMARC treats them differently? > > > > Yes. Per the DMARC definition, they are not organizational domains. > > I suggest "unable to benefit from DMARC" rather than "excluded". > "Excluded" makes me think DMARC specifically targeted them as not worthy of > or appropriate for inclusion, which isn't the case. OK. > > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > > > Because existing Organizational Domains using this PSD have their > > > own DMARC policy, the applicability of this extension is for non- > > > existent domains. The extension allows the brand protection > > > benefits of DMARC [RFC7489] to extend to the entire PSD, including > > > cousin domains of registered organizations. > > > > > > An example would be useful here. > > > > I've added this: > > As an example, take the ".gov.example" described above and add that > > for this entity emails about tax returns are sent from > > tax.gov.example. It would not be surprising if fraudulent emails > > were sent purporting to be from taxes.gov.example (taxes is a cousin > > of tax - different enough to evade DMARC protection, but similar > > enough to potentially confuse users). As defined in DMARC [RFC7489], > > a DMARC record could be published for tax.gov.example, but there is > > no general solution to publishing a DMARC policy to defend against > > abuse of non-existent cousins such as taxes.gov.example. While an > > explicit record could be published for this one domain, the universe > > of possible cousins is such that this approach does not scale. > > > > How's that? > > Great, and it's also pretty much what I proposed above. (Apologies; my > read-ahead failed.) I suggest picking one or the other, but I think it's > of benefit to put this higher up where my suggestion is to set context. OK. I'm fine with either. > > Due to the design of DMARC [RFC7489] and the nature of the Internet > > > > > email architecture [RFC5598], there are interoperability issues > > > associated with DMARC [RFC7489] deployment. These are discussed in > > > Interoperability Issues between DMARC and Indirect Email Flows > > > [RFC7960]. These issues are not applicable to PSDs, since they > > > (e.g., the ".gov.example" used above) do not send mail. > > > > > > DMARC doesn't need to be followed by its RFC number every time. > > > > I went through and removed most of these. I tried to remove them so that > > it's > > mostly there when talking about DMARC the RFC, not DMARC the protocol. > > Yeah I think you got most of them but there are a few I would still > reduce. Not a big deal unless others concur; the RFC Editor will probably > chime in as well. OK. No further changes planned then. > > 2.2. Public Suffix Domain (PSD) > > > > > The global Internet Domain Name System (DNS) is documented in > > > numerous Requests for Comment (RFC). It defines a tree of names > > > starting with root, ".", immediately below which are Top Level Domain > > > names such as ".com" and ".us". They are not available for private > > > registration. In many cases the public portion of the DNS tree is > > > more than one level deep. PSD DMARC includes all public domains > > > above the organizational level in the tree, e.g., ".gov.uk". > > > > > > I don't know what that last sentence means. PSD DMARC is an > > > extension; how does it include domains? > > > > Deleted the sentence. I don't think it is necessary for the definition, > > so > > let's not confuse things. > > The text present now for 2.2 defines the name/label structure of the DNS, > but doesn't actually say what a PSD is. > > This is an interesting problem, because we are attempting to describe (or > ascribe) semantics of the DNS that simply do not exist. The DNS is a > hierarchical naming structure and related database, plain and simple; we > are attempting to ascribe to it boundaries that are not there in DNS-land. > But we happen to do lookups in it using DNS APIs. > > So let's try removing the DNS from the definition: > > The domain name structure consists of a tree of names, each of which is > made of a sequence of words ("labels") separated by period characters. The > root of the tree is simply called ".". The Internet community at large, > through processes and policies external to this work, selects points in > this tree at which to register domain names "owned" by independent > organizations. Real-world examples are ".com", ".org", ".us", and > ".gov.uk". Names at which such registrations occur are called Public Suffix > Domains (PSDs), and a registration consists of a label selected by the > registrant to which a desirable PSD is appended. For example, "ietf.org" > is a registered domain name, and ".org" is its PSD. > > While I'm here, I suggest 2.3 is a little terse. Maybe: > > The longest PSD is the PSD matching more labels in the domain name under > evaluation than any other PSL entry. I'm fine with both. > > 3.2. Section 6.1 DMARC Policy Record > > > > > PSD DMARC records are published as a subdomain of the PSD. For the > > > PSD ".example", the PSO would post DMARC policy in a TXT record at > > > "_dmarc.example". > > > > > > Don't you mean the PSD DMARC record is a record in the zone of the > > > PSD? It's not a subdomain. > > > > Here's what's in RFC 7489 about DMARC record publishing: > > > > 6.1. DMARC Policy Record > > > > Domain Owner DMARC preferences are stored as DNS TXT records in > > subdomains named "_dmarc". For example, the Domain Owner of > > "example.com" would post DMARC preferences in a TXT record at > > "_dmarc.example.com". > > > > I think our 3.2 is equivalent and adequate given this section is a > > modification > > to RFC 7489 Section 6.1. I did not make a change. > > Embarrassing. RFC7489 6.1's text you cited is unfortunate. I would change > "in subdomains named" to "at labels named". > > But also, why do we need this section? The PSD DMARC record is in the same > place as one would expect it having read only RFC7489, correct? On reflection, I think it can be deleted. Anyone else? > > > 3.4. Section 6.6.3. Policy Discovery > > > > > A new step between step 3 and 4 is added: > > > > > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > > > > > > Organizational Domain is one that the receiver has determined is > > > acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for > > > a DMARC TXT record at the DNS domain matching the longest PSD > > > (Section 2.3) in place of the RFC5322.From domain in the message > > > (if different). A possibly empty set of records is returned. > > > > > > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I > > > don't know what "acceptable for PSD DMARC" might mean. > > > > Changed to: > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > > > > Organizational Domain is one that the receiver has determined is > > acceptable for PSD DMARC (discussed in the experiment description > > (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC > > TXT record at the DNS domain matching the longest PSD > > (Section 2.3) in place of the RFC5322.From domain in the message > > (if different). A possibly empty set of records is returned. > > > > > > Section numbers in the prose of this section should make clear which > > > document they're referencing. > > > > I checked and any reference to an RFC7489 paragraph number that's in the > > text > > is labeled as such. > > I'm talking about the "Section 2.3" here, and the "Section x.y" strings in > the section headings in Section 3. Since you are pointing back to RFC7489 > frequently, I thought it might be best to say "Section 2.3 of this > document", or "Section x.y of RFC7489", as appropriate. Since (as an example) 'longest PSD (Section 2.3)' comes from the XML longest PSD, I'm not sure how to manage that in xml2rfc language. If anyone knows how, please let me know and I'll be glad to do it. > Also in the example in the paragraph below here in the document, you're > using ".cctld"; should that be ".example" or ".cctld.example"? OK. > One final thing: I added a sentence at the end of my proposed Abstract that > tries to highlight that domains on the PSL also need to be checked and not > special-cased when one receives mail from a PSL. In order to tie it to the > experiment, I suggest this (as a new section at the end; reorder at your > discretion): > > 3.7. PSDs Are Eligible For DMARC > > Experience with DMARC has shown that some implementations short-circuit > messages, bypassing DMARC policy application, when the domain name > extracted by the receiver (from the RFC5322.From) is on the PSL. This > prevents the capability being created by this specification. Therefore, > the following paragraph is appended to Section 6.6.1 of RFC7489: > > Note that domain names that appear on the Public Suffix List are not exempt > from DMARC policy application and reporting. OK. From nobody Fri Aug 2 15:49: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 6216612004D for ; Fri, 2 Aug 2019 15:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 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.201, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=EQcCfLrp; dkim=pass (1536-bit key) header.d=taugh.com header.b=WwGbysSl 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 kb4LiV4R8Xfs for ; Fri, 2 Aug 2019 15:49:19 -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 18F8D120024 for ; Fri, 2 Aug 2019 15:49:18 -0700 (PDT) Received: (qmail 42928 invoked from network); 2 Aug 2019 22:49:17 -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=a7ad.5d44bded.k1908; i=printer-iecc.com@submit.iecc.com; bh=DZoZZ3EkKmT5eLvrWSQ1xIGeNpfod116JYfe93SSawU=; b=EQcCfLrpbCOJuKFfSfi1v8owzBpx9m2YOp89wEFxeDV3WfF0TnzaFMx6stjSSdFWnbowSBtMk/9hefeuSFophOKpAD3W0IV4sRyNByOYFO25pCsHpoc4r+BZR83Q2X9eVYL3/ZENcaa/spivM4ddz+ykhey1f0vb0av6IwehukihWeKSn7e2O+NuFNolyqxZ1Otv6XbxZh3L7xFmgx/u6njf+e7dhh19gAN8U3OU1zDWUhr17M6wAyat0UBPtOUs 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=a7ad.5d44bded.k1908; olt=printer-iecc.com@submit.iecc.com; bh=DZoZZ3EkKmT5eLvrWSQ1xIGeNpfod116JYfe93SSawU=; b=WwGbysSls1MTVF4Vg6i7R9XospMtxMCb/sh1/Fe7XsyvA6mqvrHWc4BRO+AGDH3xL5kgV8r0vrCssHRXqecOvVqFfEP9d+PR5RDxHSizpKf83R36TFIVZMbN8J3YfPnLHwYg9Kx1FkEFwamZGTjT0Zi3ycpugm7cewftLGVWCaiAwHWxYckZ7GIzwXOjIvs4lDR2z1ej+eS3PJ5WGkUiI7VnZ15I1ifb+WsSXJZ/5d80etbAKx35CGKl68IUuVVX 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, printer@iecc.com) via TCP; 02 Aug 2019 22:49:17 -0000 Received: by ary.qy (Postfix, from userid 501) id 331FB75B032; Fri, 2 Aug 2019 18:49:17 -0400 (EDT) Date: 2 Aug 2019 18:49:17 -0400 Message-Id: <20190802224917.331FB75B032@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org 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] New proposed wording for p=quarantiine 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, 02 Aug 2019 22:49:20 -0000 In article you write: >Current wording for p=quarantine > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check be treated by Mail Receivers as > suspicious. Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > >Amendment to the wording for p=quarantine: > >… or reject at SMTP level. ... No. We really, really, don't like changes that aren't backward compatible. You can do what you want but there is no chance I would ever make p=quarantine a signal to reject, and I think I am not atypical. R's, John PS: You can of course do whatever you want on your own system. From nobody Fri Aug 2 19:06:25 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E557D120043 for ; Fri, 2 Aug 2019 19:06:23 -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 ASkWthTK_CYU for ; Fri, 2 Aug 2019 19:06:22 -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 0CA5012002F for ; Fri, 2 Aug 2019 19:06:21 -0700 (PDT) Authentication-Results: mail.aegee.org/x7326IFm017333; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564797979; i=dkim+MSA-tls@aegee.org; r=y; bh=piolxH7Npy+TC6nyP5hSculDaai3apNU7s8XlmWRboI=; h=Subject:From:To:Date:In-Reply-To:References; b=QIt2bz1mPPpeSzxo8nar5MRVfj6uHq21BoU4QwGsLxpOHnC4eydz+n/cZNO8AQXJX 3cznJynio7L39Zagudl0A6aNleOi1sSjWATEmJYVp/l2WojW5p2aZrWTA2YCMirNHL 0PN34UBVnXh/GfLwv9e9ECDgYwiTgD19tQ8wPq7rzFoD37Z1eltj4tdVMBJHeRZqjN aNNFZLQwAUrU4fd6gc47VYkzG3wZVT6PTdlWKUHKkwlKk9JH7gzi5Fd3BTbMgoP++S bgdDq63/sX6ljwdWuTMLqGXq3NYXNzIUhWnfGOhSNtUmeSekVz8Zf3fzWC7i9gq49j 5VC9ivnqhg425R193ehn48FldsMkbV7ZPTQ0iONlkHFS68NkE95TYesGbfhT9I3UAw ZkHt4/8cSRnlMuD0MckWnkwZi3lqTM1//N3caVnWSRD3dOiSh5sKKRxjCCMRFJ84Yp IZSSQaAsI8hy8tcNLpojXABKC/awgz0rU5oNJajmJ8zjAy4K8U4BjhC5mI7aU7Nlfz 5EIX1hb9RLS0b9Fb4KqHgQ6BXar+mfpxt8iS9b3EG2f1VZoylQq1ga6Z/nG6SRgOSy MvyJTitKOJh0u73HsxeeZGFBIp5AuzZJbIOxXMaMpHtppDoiyZTfEmcR86ocR2JmCC tzc2ez971K0CByxCnX8Tf1qk= Authentication-Results: mail.aegee.org/x7326IFm017333; 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 x7326IFm017333 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 3 Aug 2019 02:06:19 GMT Message-ID: <97b7d4320e77f9be84703677eba79686ec769f75.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: John Levine , dmarc@ietf.org Date: Sat, 03 Aug 2019 02:06:18 +0000 In-Reply-To: <20190802224917.331FB75B032@ary.qy> References: <20190802224917.331FB75B032@ary.qy> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] New proposed wording for p=quarantiine 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, 03 Aug 2019 02:06:24 -0000 Hello John, the "... reject at SMTP level" is at least for messages, directed to an address, which does not support the concept of quarantining. Please propose what shall a site do, receiving a message, subject to quarantining, for an address, that does not support quarantining. Regards Dilyan On Fri, 2019-08-02 at 18:49 -0400, John Levine wrote: > In article you write: > > Current wording for p=quarantine > > quarantine: The Domain Owner wishes to have email that fails the > > DMARC mechanism check be treated by Mail Receivers as > > suspicious. Depending on the capabilities of the Mail > > Receiver, this can mean "place into spam folder", "scrutinize > > with additional intensity", and/or "flag as suspicious". > > > > Amendment to the wording for p=quarantine: > > > > … or reject at SMTP level. ... > > No. We really, really, don't like changes that aren't backward > compatible. You can do what you want but there is no chance I would > ever make p=quarantine a signal to reject, and I think I am not > atypical. > > R's, > John > > PS: You can of course do whatever you want on your own system. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Aug 2 20:05:35 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF712004D for ; Fri, 2 Aug 2019 20:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, 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=dL63tLTP; dkim=pass (1536-bit key) header.d=taugh.com header.b=QO2pWN6J 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 X77_QAi9371I for ; Fri, 2 Aug 2019 20:05:34 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EF4120046 for ; Fri, 2 Aug 2019 20:05:33 -0700 (PDT) Received: (qmail 83313 invoked from network); 3 Aug 2019 03:05:32 -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=1456f.5d44f9fc.k1908; i=printer-iecc.com@submit.iecc.com; bh=H3JKLX6DnxmYV+E3BeFucBknQquGFw5wHJwKCsf+3dE=; b=dL63tLTP1PcjsCzq6mCM7+cIyPSzCmpt82vIpU6v6JZZzsYJzG3m5bs+cqGXZr6MEuRLIu5aBqPQ7wOnETW+HDmrPaHHxa9M5UwTo1Krcx2WevUlTbAe+97d2XFbdleU2ssNHyXddNWoSUeyyEAQx59yWW12PBRBBywQIPipjL1witBAex8CJ7S/H1gvYmEAScFugQF5Rz4KFoNLmPlD47fN+Cs82mSd+ZxvwD9pfvAZp0LdgpZt6RG/r3ia6vcN 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=1456f.5d44f9fc.k1908; olt=printer-iecc.com@submit.iecc.com; bh=H3JKLX6DnxmYV+E3BeFucBknQquGFw5wHJwKCsf+3dE=; b=QO2pWN6JCcKTk15tIS2NimqXHHrxLh9A/t+KHRBCgtYfYcZ7ZhvDW5SS7bwGFOMHnCat8r0rk7EPfmCHG5NFFN3GT8f7cqbiwZhHZdu8cPU4PWzccS9AnMV0KKHnmwGNmxszHGCnATTmHvxC+x7eT1/hh8fcpnG+Zfx2ylv/4i6VWqHVppaujhlXUK+JeRRTzUUDssthL/cS3xQUHpgycj3P0SVPktI9dIeHzxKh5PF1yiZS8E/w9x/NsbJmhbqJ 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, printer@iecc.com) via TCP; 03 Aug 2019 03:05:32 -0000 Received: by ary.qy (Postfix, from userid 501) id 1D33375D900; Fri, 2 Aug 2019 23:05:31 -0400 (EDT) Date: 2 Aug 2019 23:05:31 -0400 Message-Id: <20190803030532.1D33375D900@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org In-Reply-To: <97b7d4320e77f9be84703677eba79686ec769f75.camel@aegee.org> 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] New proposed wording for p=quarantiine 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, 03 Aug 2019 03:05:34 -0000 In article <97b7d4320e77f9be84703677eba79686ec769f75.camel@aegee.org> you write: >Hello John, > >the "... reject at SMTP level" is at least for messages, directed to an address, which does not support the >concept of >quarantining. > >Please propose what shall a site do, receiving a message, subject to quarantining, for an address, that does >not support quarantining. It should do what RFC 7489 says: ... Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". Are you really saying your mail system has no spam folders, no way to adjust spam filtering, and no way to mark messages as suspicious (e.g., add "PROBABLY SPAM" to the subject line)? If the problem is that it's an address that goes to some software robot rather than being seen by people, do whatever you want. That's an edge case for DMARC. R's, John From nobody Fri Aug 2 20:45: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 B020012006D for ; Fri, 2 Aug 2019 20:45:29 -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 s5CbHd64BROl for ; Fri, 2 Aug 2019 20:45:27 -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 686C212001A for ; Fri, 2 Aug 2019 20:45:27 -0700 (PDT) Authentication-Results: mail.aegee.org/x733jOn9016312; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564803925; i=dkim+MSA-tls@aegee.org; r=y; bh=UgSuSP12zlgGv35RiKbuJiDqzfjweVybn4tPguViogk=; h=Subject:From:To:Date:In-Reply-To:References; b=XLNvWtyiDRCVsIqfedLtQhl/bIp/wyFw1seG5P1NqPoozMD7BVlKZ7noqE/+pWoCx tMJHTqVDb51G6hXoeelPLFDVR3GpKDSQgvq5L7Hk4iztuYqLZNUBggNU3pShTzMh3+ Cyp/qLTTK4a5Od4Ng5K+QAecxS4l+KNCAyPVHZnnNNPjpQAby1KiEDmxMsx335fDcg 5vKVqZEjCiunnUYCk4t4kBO2vvaG6VdhVzoWs32uw1VehPXv8FFv6CMAsFS+PqtlHb X2JVS20lBsOtz/YLT9KLI+fW9WXFVg075v6bA5ilWJMxyeNx/w6+Q5+RnyxS4YTd+N qacf0KF0KmaCLqIFGHXuzPp+rZqM7JZPmnRJqftinafo20Sd5LN7y/DSxMxAByNPR3 INn9RMqrJOWeSL4xVVWCmyic9JY313uRWlTjcjZHzxrzVTG09CImd2/Jw0bNRRIgGs jpR4wcMn4jmQHptnIglzgxZO0+PHjxPhx8a2uBkdSsLIka9vgi2vCpwRsmcmqlDbKF oHuEttD45YoBOfZcvghGwYVkrdLXXPVW+Uk8H7ipPgxTYZo09B5nc61rlNzHreGubc A8/hZ3DDC7Ns+rQpUNGnqZlVgtvAc77SlATm3EzidBRGep5UkWbuOMZ+Fxz1hd1Zrv iAwZaEeacb3ybHyeMiO5VcRM= Authentication-Results: mail.aegee.org/x733jOn9016312; 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 x733jOn9016312 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 3 Aug 2019 03:45:24 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: John Levine , dmarc@ietf.org Date: Sat, 03 Aug 2019 03:45:24 +0000 In-Reply-To: <20190803030532.1D33375D900@ary.qy> References: <20190803030532.1D33375D900@ary.qy> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] New proposed wording for p=quarantiine 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, 03 Aug 2019 03:45:30 -0000 Hello John, I am really saying, that some addresses, like majordomo@ , which send answer to each received and accepted message, have no capability to perform a form of “quarantine”. It does not matter, whether this is an edge case. Once it is clarified how to act in this case, the same procedure can be applied to mailboxes, where users want to have no Spam folder. So mailboxes, which capability to quarantine messages is disabled and for users, who do not want to receive messages with SUSPICIOUS in the subject line or have any corresponding headers. Or for users who statistically never open their Spam folder. So it is a matter of clarifying what the domain owner wishes by publishing p=quarantine to happen to messages failing DMARC validation, when the receiving address, voluntary or not voluntary, does not offer quarantining capability. I have no problem, if the text "... reject at SMTP level" is not attached to the quarantine definition, but is implied by reading other passages. Then it does not make a difference. Regards Дилян On Fri, 2019-08-02 at 23:05 -0400, John Levine wrote: > In article <97b7d4320e77f9be84703677eba79686ec769f75.camel@aegee.org> you write: > > Hello John, > > > > the "... reject at SMTP level" is at least for messages, directed to an address, which does not support the > > concept of > > quarantining. > > > > Please propose what shall a site do, receiving a message, subject to quarantining, for an address, that does > > not support quarantining. > > It should do what RFC 7489 says: > > ... Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > > Are you really saying your mail system has no spam folders, no way to > adjust spam filtering, and no way to mark messages as suspicious > (e.g., add "PROBABLY SPAM" to the subject line)? > > If the problem is that it's an address that goes to some software > robot rather than being seen by people, do whatever you want. That's > an edge case for DMARC. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Aug 3 00:02: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 5E69B120111 for ; Sat, 3 Aug 2019 00:02:32 -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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=t77Ud3Y0; dkim=pass (2048-bit key) header.d=kitterman.com header.b=MKyK1zcF 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 q-UE_AAuP40Z for ; Sat, 3 Aug 2019 00:02:30 -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 D95B9120108 for ; Sat, 3 Aug 2019 00:02:29 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B1249F8049F; Sat, 3 Aug 2019 03:02:28 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564815748; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=+vJUmVFTtC2L7fI7PAujcFz4NTPBiliLc5Seo0qY/mg=; b=t77Ud3Y0ZzhhdKB8B2uVXWyfV3BLsuDTNZb0eYwSvHF967PF7mKpYeAV e7N/hlgpXfVqJDW/4/8zsEgX+GD/BA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564815748; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=+vJUmVFTtC2L7fI7PAujcFz4NTPBiliLc5Seo0qY/mg=; b=MKyK1zcFFc+Ksu1Rs305+tlvsoPwO81OcxPnk8sJ9KsJuubCpcQXa8l1 I50wbB7PBwziEgbxZNymMDMW5Co+MX/MJQXG/Q/H+Txm+eGInxaXyqBGbL kj07xsEW7eanJzSEejKdbnqpQaS4xeNZs0PPVAc+To7WWgKR6YmzXbHSVu ewUj5NzsgQeNsrhrRbBGw4JcA+ufhgMWC2J2api1Fjp2WgiCShyZBuqInj uVhVOQWqg0jvxf61stRLeegOA53dYHsINzqkr1YUClC8jyIYNMdAMYjiT7 ba58kHKkZeyNi0vtEcF8R+iICF7l04EHSVxvAa9dKMVH/3Hvrr8VPg== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 7DF72F80499; Sat, 3 Aug 2019 03:02:28 -0400 (EDT) Date: Sat, 03 Aug 2019 07:02:26 +0000 In-Reply-To: References: <20190803030532.1D33375D900@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <0CB7D475-6DDE-403D-BA65-E38C89A6D90A@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] New proposed wording for p=quarantiine 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, 03 Aug 2019 07:02:32 -0000 Policy is an indication of sender preference, not a directive the receiver= must follow=2E I think the definition is fine=2E If the sender prefers f= ailing messages be quarantined, then they should use that policy=2E They w= on't get what they want in all cases and that's fine=2E Scott K On August 3, 2019 3:45:24 AM UTC, "=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 John, > >I am really saying, that some addresses, like majordomo@ , which send >answer to each received and accepted message, have >no capability to perform a form of =E2=80=9Cquarantine=E2=80=9D=2E > >It does not matter, whether this is an edge case=2E Once it is clarified >how to act in this case, the same procedure can >be applied to mailboxes, where users want to have no Spam folder=2E So >mailboxes, which capability to quarantine messages >is disabled and for users, who do not want to receive messages with >SUSPICIOUS in the subject line or have any >corresponding headers=2E Or for users who statistically never open their >Spam folder=2E > >So it is a matter of clarifying what the domain owner wishes by >publishing p=3Dquarantine to happen to messages failing >DMARC validation, when the receiving address, voluntary or not >voluntary, does not offer quarantining capability=2E > >I have no problem, if the text "=2E=2E=2E reject at SMTP level" is not >attached to the quarantine definition, but is implied >by reading other passages=2E Then it does not make a difference=2E > >Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > > > >On Fri, 2019-08-02 at 23:05 -0400, John Levine wrote: >> In article <97b7d4320e77f9be84703677eba79686ec769f75=2Ecamel@aegee=2Eor= g> >you write: >> > Hello John, >> >=20 >> > the "=2E=2E=2E reject at SMTP level" is at least for messages, direct= ed >to an address, which does not support the >> > concept of >> > quarantining=2E >> >=20 >> > Please propose what shall a site do, receiving a message, subject >to quarantining, for an address, that does >> > not support quarantining=2E >>=20 >> It should do what RFC 7489 says: >>=20 >> =2E=2E=2E Depending on the capabilities of the Mail >> Receiver, this can mean "place into spam folder", >"scrutinize >> with additional intensity", and/or "flag as suspicious"=2E >>=20 >> Are you really saying your mail system has no spam folders, no way to >> adjust spam filtering, and no way to mark messages as suspicious >> (e=2Eg=2E, add "PROBABLY SPAM" to the subject line)? >>=20 >> If the problem is that it's an address that goes to some software >> robot rather than being seen by people, do whatever you want=2E That's >> an edge case for DMARC=2E >>=20 >> R's, >> John >>=20 >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc > >_______________________________________________ >dmarc mailing list >dmarc@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dmarc From nobody Sat Aug 3 08:28: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 A4A6C1200C3 for ; Sat, 3 Aug 2019 08:28:17 -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 V7L1nXtHv3k7 for ; Sat, 3 Aug 2019 08:28:16 -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 3B78912008F for ; Sat, 3 Aug 2019 08:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564846093; bh=fxkxS/n7IdepFSFx6J0tHIw4XUelW6MwGARBIJJwOqo=; l=1207; h=To:References:From:Date:In-Reply-To; b=AHj4tnw/OJNwX/5d2bKzLSpAZMhAUx1+fLNJ0pwzsCIYo2C+DlOtSwyebQTPaPqHX LHxQIOBAY2RPAuYRWvPsUK1Jx9i9pUCDt284sPe8kZTMBjNNtPGIw4/mjif8wTwCqg MoGGRhVrtD55bh4O/SrdBofKjvHz3LtgbtJfOmraT9zXixMfWEH/ozsjjuZ/V Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC042.000000005D45A80D.00000696; Sat, 03 Aug 2019 17:28:13 +0200 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Sat, 3 Aug 2019 17:28:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 15:28:18 -0000 On Fri 02/Aug/2019 21:58:30 +0200 Murray S. Kucherawy wrote: > > Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"? > I would expect it to have that knowledge, not downstream things. Again, I > don't know what the value of "dnswl=pass" is if the thing attaching it > doesn't even know how to interpret the result it got. If the A-R producer could interpret the encoding then it could write something like policy.trustworthiness=x instead of policy.ip=127.x.y.z. However, in the words of rfc5782: There is no widely used convention for mapping sublist names to bits or values, beyond the convention that all A values SHOULD be in the 127.0.0.0/8 range to prevent unwanted network traffic if the value is erroneously used as an IP address. It turned out that there is no simple syntax to configure which bits of the A value bear which meaning. For usability reason, in the case at hand, the syntax was simplified by requiring the color of the zone, that is[*]: -block=zone[,var[/n.n.n.n][,msg]] or -allow=zone[,var[/n.n.n.n[,]]] IOW, dnswl=pass means the sender was whitelisted. Best Ale -- [*] https://www.courier-mta.org/couriertcpd.html From nobody Sat Aug 3 08:40: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 6138412008F for ; Sat, 3 Aug 2019 08:40:27 -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 kGrxMyTvu_Us for ; Sat, 3 Aug 2019 08:40:26 -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 0D85C12008B for ; Sat, 3 Aug 2019 08:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564846823; bh=/0ffeyS0dXtrucm5BdlPbkMbEojx0GYoNfjTYh1OSLQ=; l=617; h=To:References:From:Date:In-Reply-To; b=A5BDZS+Ph1WShFYvJHnaxFkLsWG4/GMER625zOxlfh3FtrB8Mb6Z35XPpH0ZaVHGD ZIGxz/bH/N6tbhN4xJlob5JVm+DMd4rjGwXYSzGkdzqeKpJbCfT6//K3ZRRG76w2U1 ZuGFKH7540wRWwNnAwgXNYI3NFurfYqeUTRJ30In2v3KQ30LSVypSurcc1xdD Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC042.000000005D45AAE7.00000834; Sat, 03 Aug 2019 17:40:23 +0200 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Sat, 3 Aug 2019 17:40:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 15:40:28 -0000 On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote: > On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: > >> To stick with A-R semantics, it should have been named tcp.ip, remote.ip >> or some such.>> > > Note that RFC8617 section 10.2 ( > https://tools.ietf.org/html/rfc8617#section-10.2) does add in an > smtp.remote-ip method item. That's much better. If the definition of ptype smtp were "a parameter of the SMTP session used to relay the message" it would be perfect. I'd propose that policy.iprev be deprecated and smtp.remote-ip used instead. Best Ale -- From nobody Sat Aug 3 09:18: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 A721D1200DE for ; Sat, 3 Aug 2019 09:18: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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIj3U-tHzdSR for ; Sat, 3 Aug 2019 09:18:24 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2221200A3 for ; Sat, 3 Aug 2019 09:18:23 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1564849104; b=ALyJWrCUZPXKe8EmFoA8bSPS7pHiXayY5/N++g7b91D+3MxhhYsmvvWM2KjWdABwnW4zfC02zd 78z2X2QS7UL27EoUCoPhXe29SfpKltEMjn+4HxpFmWCAHAcKPLPB44Wl+Zhpldjl0b8b+1pB15 XMWPa3LTxgPF/vpcdyOwbB0=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1564849104; bh=7vh/tUOZpfz1aBJqrd3lt7KvVcBmhBhjefe13y7R6P4=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=cTXrPsPEIae1yjjR/Sid2JOyq6gbrTC7Own7/pJgi76Pb9t2nEEiZFzd5bIFJPXPZBouhMM7MN IlvcjZaOf35FuW2jyQcojHyAgLRIk0l7rf3+4nnizVJtbHcfEKBu8FdPejApBs2C8fMIdWar/9 z6nJRy5T9b8OuWTU/8rtJtA=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=YGOjFD4l4O6OIEr6KqOIF//g+CsFNZefVy5fhHrZbx0=; b=L htv8ikRA5JJmIc50+qiwbYriLBb7t1UbSDu0th4oJlgEhh68NVw04FTYQ/A1SvJe6uSwppCYn1bTx 9SF1WdxLtb/dRy3euGAdzMRUezscEc/PN4/TodJ2SVaGcoGI1pHLI0vI5+FoIqJb79O+JzLeaDVSl 1f3Nra9i7LH27QkE=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.92.124) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1htwjd-000256-Rq for dmarc@ietf.org (return-path ); Sat, 03 Aug 2019 16:18:21 +0000 To: dmarc@ietf.org References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <218d8acb-ed14-c63e-4fdf-4efc326913c8@wizmail.org> Date: Sat, 3 Aug 2019 17:18:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 16:18:26 -0000 On 02/08/2019 20:58, Murray S. Kucherawy wrote: > For guidance here, I would rely on anecdotes of implementation. Has anyone > implemented something that attaches "iprev" results? Exim does. -- Cheers, Jeremy From nobody Sat Aug 3 09:27: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 618E21200EC for ; Sat, 3 Aug 2019 09:27:05 -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 3NwlS8pY6V92 for ; Sat, 3 Aug 2019 09:27:04 -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 BFDD01200E6 for ; Sat, 3 Aug 2019 09:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564849621; bh=3oAylQ7T+0L3bmZ0t1QJwWKj27xV8PJlGjW0xAB3beE=; l=982; h=To:References:From:Date:In-Reply-To; b=Avpvq8l+FIbyVLtwZ/d51y8sGr/DzUE3pgWnLszbIJpQt9Krf2kZznerCePKmCeQj XSZRdgTbp9eKe2h1Xk1tWwXdOaqEKtXa8mjEQWoYJOlfs0yN9igIGjfxo107x2Ls/S +TxvEurKg0X9B4q7gA+/mvk3bdsKIA6X1oJTfqcBZLRGb9tMaq90fETiBa9jS Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC02F.000000005D45B5D5.00000D01; Sat, 03 Aug 2019 18:27:01 +0200 To: dmarc@ietf.org References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> <9ffdbe9e-7720-0a39-876e-7bfbdd0b9366@sonnection.nl> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Sat, 3 Aug 2019 18:27:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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] ESC for Failed DMARC Validation 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, 03 Aug 2019 16:27:06 -0000 Hi, On Fri 02/Aug/2019 23:27:48 +0200 Дилян Палаузов wrote: > > these are already now two ESC: 2.7.30 and 5.7.30. X.7.30 means in both cases, that DMARC validation failed. > > For a domain with policy p=reject; pct=0 the mail is delivered (250 2.7.30), despite failed DMARCр and for a domain with > p=reject; pct=100 when DMARC failed and the mail is rejected (550 5.7.30). A message can be rejected as soon as a reason to do so it is found. That principle uniquely defines the reject response. The accept response cannot collect what every filter thought about the message. To act as you propose, the DMARC filter should be granted the special privilege to set the text of the response in any case. On Courier-MTA there's no API to support that. Do Postfix or Sendmail provide one? I doubt, since SMTP doesn't attach a special significance to the text of the response, except for the 220, 221, 251, 421, and 551 reply codes. Best Ale -- From nobody Sat Aug 3 09:30:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7193F1200EC for ; Sat, 3 Aug 2019 09:30:55 -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=xNH/1zLO; dkim=pass (2048-bit key) header.d=kitterman.com header.b=mw23/BRf 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 JZC2aSa8wRaO for ; Sat, 3 Aug 2019 09:30:54 -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 220511200E6 for ; Sat, 3 Aug 2019 09:30:54 -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 E20D3F8046C; Sat, 3 Aug 2019 12:30:22 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564849822; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=u85aG+b1/zWeZulAnoYK2OzADQA6lhWe9lPr2h+Ooxk=; b=xNH/1zLOVcklW+5izR3vTkYu77LGdoVOcVrWU+GoyHno+xmJMabIc5r7 l3bXLERD7KR3nSmJsMEILeD6SRudAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564849822; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=u85aG+b1/zWeZulAnoYK2OzADQA6lhWe9lPr2h+Ooxk=; b=mw23/BRf2qAeV3i0Z1Ohf5yG+rws1yLqD/qFhmOlmX1+uxpx9ZMJH0vL vLhKcH5pHq4rgRgpN24ubQfvn8K5lqY2gZ4u5c6aXNOnJ9ahZYiHuLm+zZ 3ocJV48hXAGricKcFfz5EILRWbsn+q0DCHDU6jkCJbGGLU/NNl+ODQYZyJ kFfLOByHYza1iTflEKyXsy0A4BfTpipB+kyV7ZhWz62fCB/nb0ylDD5qBM O6ifRzxlyobrYq7a5siTmoADWjUFAToxHGQt8b85Trtx5vT61+855jaH/0 pnfEELkTaAvfBY5BkYzKFvCL2DG4NvByldh+oO5/Y8Q2Sk3a7k0euw== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 96FCEF80096; Sat, 3 Aug 2019 12:30:22 -0400 (EDT) Date: Sat, 03 Aug 2019 16:30:21 +0000 In-Reply-To: References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Do we need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 16:30:56 -0000 On August 2, 2019 7:58:30 PM UTC, "Murray S=2E Kucherawy" wrote: =2E=2E=2E >For guidance here, I would rely on anecdotes of implementation=2E Has >anyone >implemented something that attaches "iprev" results? =2E=2E=2E The authres Python module that I maintain has implemented the structure an= d has examples/tests that match what you are suggesting=2E It implements all the registered A-R variants for completeness=2E I don't= know if there are any applications that use iprev=2E Scott K From nobody Sun Aug 4 01:07: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 585BF1200D8 for ; Sun, 4 Aug 2019 01:07: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 (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 RtvPOxcOpGLn for ; Sun, 4 Aug 2019 01:07:50 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id F00AE1200D5 for ; Sun, 4 Aug 2019 01:07:49 -0700 (PDT) Received: from [192.168.0.88] (unknown [37.228.251.105]) by mail.wordtothewise.com (Postfix) with ESMTPSA id EDD599F146 for ; Sun, 4 Aug 2019 01:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1564906069; bh=1I9QbElegtdJce6kg2BzhHwbFi81fggSRyF6vjKAKsc=; h=From:Subject:Date:References:To:In-Reply-To:From; b=KSTquA+Xz19Q5xDctIsYC/YwuVa+yVDa8ywmINs8/gcLK4lMe5Az8e8J2JzJlvz/d PyNe+tQ3+CEw0a0GgqBmTfh8lIE9fNx64VROSlykc4DqyBaKNOQ+k0711fqlFaqU2f nBO0BGS6rfBfeG25zH2zuPhPK718FN1N20OGxhfw= 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: Sun, 4 Aug 2019 09:07:47 +0100 References: To: dmarc In-Reply-To: Message-Id: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] Concerns for not Sending a Failure 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: Sun, 04 Aug 2019 08:07:51 -0000 > On Aug 2, 2019, at 10:41 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 > I just thougth once again on this. >=20 > Some of the senders of aggregate reports offer free mailboxes. >=20 > Aggregate reports show that emails from a host to a provider of free = mailboxes sometimes do not validate DMARC. >=20 > The one provider sending emails opens a free mailbox on the receiver = and then sends a secret copy of each, otherwise > ordinary delivered email, to that special mailbox. >=20 > Then the mails from that mailbox are downloaded, and the A-R header is = checked. By this way the sender finds out, which > messages exactly have failed DMARC validation. >=20 > At the end the same information is obtained, that can be obtained by = exchanging a failure report: which messages have > failed. Information found in mail mail headers in accounts that you have created = includes email that's been sent to you. Information found in failure reports includes email that generally was = not sent to you. Cheers, Steve= From nobody Sun Aug 4 01:18: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 9F00D120077 for ; Sun, 4 Aug 2019 01:18:22 -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 wwLbpYG8KX6H for ; Sun, 4 Aug 2019 01:18:20 -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 00C96120086 for ; Sun, 4 Aug 2019 01:18:19 -0700 (PDT) Authentication-Results: mail.aegee.org/x748IGqe022035; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564906697; i=dkim+MSA-tls@aegee.org; r=y; bh=RR78Q3lVKq0QE+ImZrOe7e+mEAv6ke8z54CAeXCcW9M=; h=Subject:From:To:Date:In-Reply-To:References; b=cy5gUUTu5LJx3fqIavHzJqJxvR1sycklasrYRVPAdN50pxLEIuTRGyAoqviSVWzdr BXma42UcqQJGygpaASlT3pcoqpPMSd2N90uotO17qePy4HlP+wYQsE6bnRwq2KNWEv A6IHOCTG4gbr4/wxmaqubSKUiQkGM78oj1Y7JPXZbNEknTrFoqKlAxTx6ruwIko8KR dVodEFfj0G+9a/qQn+Dly0SFWtzfT5JoeGgqsmOhG/3Fy9DCwvk8w19wZRxiWtBGAN Sw+g43mB/oPOsiyiVt7c02XbmJ4ifA74QN21D8WWXUH08uyRs+3E5vqGTc1Qn6W3HL 2gKfzD4rViH69N7XPpBPJ2mnGiZj0pVCzTxiZK7g2nfxvhW+AidwbkUXPQCaKl5b9f mx7/cJbLnH6NE77b+SqBtxHXy5G8vn/GdYm4al2ODvJPEfIlfXopZFGhRBcqtjaNc/ wlgoy7O4RRjkhnurbvwwYwEzb0KS1S/hHTdn1k5GTVvkO6pgfB4Y/u+yZO3F20k695 RHOLizH6J8QlMkQ2tZIRKfWl2TuNdow5ibc0xALJlntlkelZHBWvyJXekR8rtXHpdJ Q1bhCqF8rUt4g2xKPcIIxdtfZ+B/+qQWKHUAIvemgIBxVh2f4JZQmisIMviBfZyjXw VBZ9lEWIdWqKJRwetj2EVBMo= Authentication-Results: mail.aegee.org/x748IGqe022035; 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 x748IGqe022035 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 4 Aug 2019 08:18:17 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: Steve Atkins , dmarc Date: Sun, 04 Aug 2019 08:18:15 +0000 In-Reply-To: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> References: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] Concerns for not Sending a Failure 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: Sun, 04 Aug 2019 08:18:23 -0000 Hello Steve, in both cases it is about information that was sent over from the same mailhost. To whom the information was sent decides the operator of the mailhost, not the one who suppresses failure reports. In any case, for a failure report containing only the Message-Id it does not matter what information the email carried and to whom the information was sent. Regards Дилян On Sun, 2019-08-04 at 09:07 +0100, Steve Atkins wrote: > > On Aug 2, 2019, at 10:41 PM, Дилян Палаузов wrote: > > > > Hello, > > > > I just thougth once again on this. > > > > Some of the senders of aggregate reports offer free mailboxes. > > > > Aggregate reports show that emails from a host to a provider of free mailboxes sometimes do not validate DMARC. > > > > The one provider sending emails opens a free mailbox on the receiver and then sends a secret copy of each, otherwise > > ordinary delivered email, to that special mailbox. > > > > Then the mails from that mailbox are downloaded, and the A-R header is checked. By this way the sender finds out, which > > messages exactly have failed DMARC validation. > > > > At the end the same information is obtained, that can be obtained by exchanging a failure report: which messages have > > failed. > > Information found in mail mail headers in accounts that you have created includes email that's been sent to you. > > Information found in failure reports includes email that generally was not sent to you. > > Cheers, > Steve > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Aug 4 02:35:27 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74DD12003E for ; Sun, 4 Aug 2019 02:35:25 -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 (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 VKThSOYb77pr for ; Sun, 4 Aug 2019 02:35:24 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id A720312002E for ; Sun, 4 Aug 2019 02:35:24 -0700 (PDT) Received: from [192.168.0.88] (unknown [37.228.251.105]) by mail.wordtothewise.com (Postfix) with ESMTPSA id ACF909F146 for ; Sun, 4 Aug 2019 02:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1564911323; bh=PfnduhJXd9TQOXY3IS3et5QfE3xBx2Je49KZr4pqXek=; h=From:Subject:Date:References:To:In-Reply-To:From; b=Np2r9j7RB3EmvoRCb/zSogvfl1AHlfifR2aAsAJBGlLcIS8UCRUJa2VtrXCJaL9JI vHifjRQ8kNt1FuSj7iUVzd+jCp3g7jzY5vpFplqhRPoL5KkY8qwo6ptXYQP0JvqRDY ECBtyMX1ICTL9Q2/piKkTtCcZ9Q8nTj/Qd3V8pzI= 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: Sun, 4 Aug 2019 10:35:21 +0100 References: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> To: dmarc In-Reply-To: Message-Id: <6FCCAD3E-C2EB-4613-B0C0-148AE3387D21@wordtothewise.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] Concerns for not Sending a Failure 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: Sun, 04 Aug 2019 09:35:26 -0000 > On Aug 4, 2019, at 9:18 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: >=20 > Hello Steve, >=20 > in both cases it is about information that was sent over from the same = mailhost. =20 The mailbox provider has no way of knowing that you sent the mail. If it = was authenticated as coming from you this wouldn't be an issue. One mail was sent to *you*. It's OK for you to have access to it. The other mail was sent to someone *not you*. There's no a priori reason = you should have access to the content of the message. Cheers, Steve > To whom the information was sent > decides the operator of the mailhost, not the one who suppresses = failure reports. >=20 > In any case, for a failure report containing only the Message-Id it = does not matter what information the email carried > and to whom the information was sent. >=20 > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD >=20 > On Sun, 2019-08-04 at 09:07 +0100, Steve Atkins wrote: >>> On Aug 2, 2019, at 10:41 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 >>> I just thougth once again on this. >>>=20 >>> Some of the senders of aggregate reports offer free mailboxes. >>>=20 >>> Aggregate reports show that emails from a host to a provider of free = mailboxes sometimes do not validate DMARC. >>>=20 >>> The one provider sending emails opens a free mailbox on the receiver = and then sends a secret copy of each, otherwise >>> ordinary delivered email, to that special mailbox. >>>=20 >>> Then the mails from that mailbox are downloaded, and the A-R header = is checked. By this way the sender finds out, which >>> messages exactly have failed DMARC validation. >>>=20 >>> At the end the same information is obtained, that can be obtained by = exchanging a failure report: which messages have >>> failed. >>=20 >> Information found in mail mail headers in accounts that you have = created includes email that's been sent to you. >>=20 >> Information found in failure reports includes email that generally = was not sent to you. >>=20 >> Cheers, >> Steve >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Sun Aug 4 03:11: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 AA40E120041 for ; Sun, 4 Aug 2019 03:10: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 WtL8DK_l3fLK for ; Sun, 4 Aug 2019 03:10: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 1AC5A12000F for ; Sun, 4 Aug 2019 03:10:55 -0700 (PDT) Authentication-Results: mail.aegee.org/x74AApov008316; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564913453; i=dkim+MSA-tls@aegee.org; r=y; bh=IIfzTDwrmLT2ftpMlv5jYriXRNoiZhFxYslAEJhHw44=; h=Subject:From:To:Date:In-Reply-To:References; b=AgHxpwIp/PmDsy+yHUr3sqovFZ6lWYIPBG1Tn5oA1IDJn2ownY24WsS6YjkSwk1Gk NHOC2fPTDTtAi51U2HE/zWLoZ3wBXhGwk5ooPALpnGZX/TLHkCqVD8jYBhOykok59F IgmdwTi2mGk6Qd5pyKteNNvv4ZilVKJXiSujN5jBuoD26svxXVjOM+WJS5Pf9SDl/N AVArhEjardNFn17O+XtqYu4G9onNMXZcgri1PnSQlThuuPkqMjR32AUF7KyPnLHY1P PVUstvlxq5aP8jB2e8McgB0DlpL8t4MBDEsYig0ONiGmDlWdWKOVWKpCYb7Ph2F9EM Q551WcmZGb+1vvNk/R739oYWD05YGN4yKC6WoGoDfj2W6htctAncaMiXcPNvNCPLHY lespcVlFr1z3TiLnhtbpSTV4YBu0jq+aHMIoshScVWOOqb+fisqly0OnXH3lLIduSP dCV5haWpP6bceklkeEGiIFwSqCbIqS3gPm57o876fv1PM2qpJa4pX66/UbGlk03dxg SvAQ3ufXRG4I6ye/d/diTd6oetnxGG3VFvrliZs6FLU2FktBlcFj/D/d1PyjFXlUrD ZVhV5kflmfM2nd9ERyDt+Rx5Nb/vk40nY6DRpn7NRHGeiPvyYYYWRoQWcD72vlY+MS NWtpn+RHmXOaiSx0gAZrJd/I= Authentication-Results: mail.aegee.org/x74AApov008316; 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 x74AApov008316 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 4 Aug 2019 10:10: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: Steve Atkins , dmarc Date: Sun, 04 Aug 2019 10:10:51 +0000 In-Reply-To: <6FCCAD3E-C2EB-4613-B0C0-148AE3387D21@wordtothewise.com> References: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> <6FCCAD3E-C2EB-4613-B0C0-148AE3387D21@wordtothewise.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] Concerns for not Sending a Failure 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: Sun, 04 Aug 2019 10:10:59 -0000 Hello Steve, do you mean, that a mailhost sending emails for a particular domain, protected by restrictive DMARC policy, has no authority to decide, that persons appointed by the mailhost provider can read any email and any report? I mean, a domain @A.int publishes “p=reject; ruf=z@a.int” and sends all emails over host mail.a.int . The provider gives access to all (sent) emails to person Z. Does publishing ruf=z@a.int, by the domain owner mean, that the domain owner is capable to ensure that the persons who receive the failure reports and the persons who can read all sent mails from @a.int are the same persons? Or it means, that the domain owner is not capable to make such decision? Z is capable to sent a copy of all outgoing mails indended for a particular provider to a dedicated mailbox at that provider, fetch then the emails from the dedicated mailbox and filter the ones with Authentication-Result: dmarc=fail . > The mailbox provider has no way of knowing that you sent the mail. If it was authenticated as coming from you this wouldn't be an issue. The receiving server knows, which IP address sent the mail and it knows, to which IP addresses set the failure report will go. If there is a match in the IP addresses, then the receiving server knows that the one who will get the report is also the one, who has anyway access to the message. I think now, that not sending failure reports has nothing to do with (privacy) concerns. It is either laziness of the receiving site to make the appropriate setup, or unwillingness to reveal information about mismatching DKIM implementation of sender and receiver. With willingness to align the implementations, a receiving site having (privacy) concerns, can offer a mailbox to the sending site, where the sending mailhost duplicates each email from the sending to the receiving host. Then the sending host can fetch the mails and look for A-R: dmarc=fail. That said I would like to see some text in the revisited DMARC specification about obtaining information about messages failing DMARC, sent from a particular mailhost to another mailhost, when the receiving site does not send failure reporst (for any reason), but is otherwise willing to exchange information about messages, failing DMARC validation. Regards Дилян On Sun, 2019-08-04 at 10:35 +0100, Steve Atkins wrote: > > On Aug 4, 2019, at 9:18 AM, Дилян Палаузов wrote: > > > > Hello Steve, > > > > in both cases it is about information that was sent over from the same mailhost. > > The mailbox provider has no way of knowing that you sent the mail. If it was authenticated as coming from you this wouldn't be an issue. > > One mail was sent to *you*. It's OK for you to have access to it. > > The other mail was sent to someone *not you*. There's no a priori reason you should have access to the content of the message. > > Cheers, > Steve > > > > To whom the information was sent > > decides the operator of the mailhost, not the one who suppresses failure reports. > > > > In any case, for a failure report containing only the Message-Id it does not matter what information the email carried > > and to whom the information was sent. > > > > Regards > > Дилян > > > > On Sun, 2019-08-04 at 09:07 +0100, Steve Atkins wrote: > > > > On Aug 2, 2019, at 10:41 PM, Дилян Палаузов wrote: > > > > > > > > Hello, > > > > > > > > I just thougth once again on this. > > > > > > > > Some of the senders of aggregate reports offer free mailboxes. > > > > > > > > Aggregate reports show that emails from a host to a provider of free mailboxes sometimes do not validate DMARC. > > > > > > > > The one provider sending emails opens a free mailbox on the receiver and then sends a secret copy of each, otherwise > > > > ordinary delivered email, to that special mailbox. > > > > > > > > Then the mails from that mailbox are downloaded, and the A-R header is checked. By this way the sender finds out, which > > > > messages exactly have failed DMARC validation. > > > > > > > > At the end the same information is obtained, that can be obtained by exchanging a failure report: which messages have > > > > failed. > > > > > > Information found in mail mail headers in accounts that you have created includes email that's been sent to you. > > > > > > Information found in failure reports includes email that generally was not sent to you. > > > > > > Cheers, > > > Steve > > > _______________________________________________ > > > 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 Sun Aug 4 03:26: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 B9730120026 for ; Sun, 4 Aug 2019 03:26:12 -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 a9rgUuySEDfk for ; Sun, 4 Aug 2019 03:26:11 -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 60B60120025 for ; Sun, 4 Aug 2019 03:26:11 -0700 (PDT) Authentication-Results: mail.aegee.org/x74AQ8Al012036; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564914368; i=dkim+MSA-tls@aegee.org; r=y; bh=at+PY+yAdtMunshVcyPvaHosomNNuaQWyeyJuVbgmzI=; h=Subject:From:To:Date:In-Reply-To:References; b=JgWGXkMYTBdOQZA50m3FrIaQSh+RXcwYR6VRfFhhFrKu+DJwWI6MfXHAlSxJ79YX2 dwqChpJW5zXPJkupuM692hCqK1Ku4ZLhqfs3+7FzpvDUq7p+hg1qsEBfkRgSUADYS0 qRuZpyZIdeJL+8AjXPckshIUJ7lCRKCLBg71YiqCwvx8OydBCW2L65/RAPiYWbi0vp oi5rh3aWrV6bzqI0I+koivk81/5ZZmIH30Wqa9YY8Sx/jE2m7DnITDO4sr0oxrurfn QSFVEKt0J7qDkqjLoutDqvivCdJU5SGcw8QxsRkbvXgVejacmD//Usp9qgeX3tXcPd lnGP3Syub27JgW7Zw28UdrkD+h9IieepMm5wtPJ9+MY03WPz2Xnk1sV/hWireQWdpa qFke43U3S2ouQlVP3qJEk9ztbsmCvH6O0xNjHPT3EVZejj7jvPggYC5NcK6nF9IhfF LYvtnlPDzrDdKE4/CQlblSQi6zskVZyJC3NxKPz4o3Wuct6YZOpW9/2VWthUh9Hgf7 b2+2KcLuTjHc9HTNJmjmvtBU6lvICR3Xy3Mn3pbzXmCw2JoZ2IoZ4SfRiIDbgEkAQp s7ESWON3weJaIotWH8mYVwrgIq6C96GP5m1PhpwIWN7wC24s/Zwij56WLQ/+lRnkVl 6BlpJPlZUegYsGSG+N46Lupc= Authentication-Results: mail.aegee.org/x74AQ8Al012036; 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 x74AQ8Al012036 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 4 Aug 2019 10:26:08 GMT Message-ID: <01a00560683ca238b1f9b4f160e5f1395ec1d572.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: Alessandro Vesely , dmarc@ietf.org Date: Sun, 04 Aug 2019 10:26:07 +0000 In-Reply-To: References: <22f0d022-57f7-8b8f-0d88-18d1c77e990e@tana.it> <505750d4fb9c03050508255594c55f4517da3e6d.camel@aegee.org> <9ffdbe9e-7720-0a39-876e-7bfbdd0b9366@sonnection.nl> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] ESC for Failed DMARC Validation 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, 04 Aug 2019 10:26:13 -0000 Hello Alessandro, if a site wants to emit X.7.30, it will find a way to do so (sometimes or always). I prefer an ESC over an SMTP service extension, since I consider ESCs as much easier to implement and otherwise both options are the same. Regards Дилян On Sat, 2019-08-03 at 18:27 +0200, Alessandro Vesely wrote: > Hi, > > On Fri 02/Aug/2019 23:27:48 +0200 Дилян Палаузов wrote: > > these are already now two ESC: 2.7.30 and 5.7.30. X.7.30 means in both cases, that DMARC validation failed. > > > > For a domain with policy p=reject; pct=0 the mail is delivered (250 2.7.30), despite failed DMARCр and for a domain with > > p=reject; pct=100 when DMARC failed and the mail is rejected (550 5.7.30). > > A message can be rejected as soon as a reason to do so it is found. That > principle uniquely defines the reject response. The accept response cannot > collect what every filter thought about the message. To act as you propose, > the DMARC filter should be granted the special privilege to set the text of the > response in any case. > > On Courier-MTA there's no API to support that. Do Postfix or Sendmail provide > one? I doubt, since SMTP doesn't attach a special significance to the text of > the response, except for the 220, 221, 251, 421, and 551 reply codes. > > > Best > Ale From nobody Sun Aug 4 03:55: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 E56F0120026 for ; Sun, 4 Aug 2019 03:55:16 -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 G6_bH5S_UjzZ for ; Sun, 4 Aug 2019 03:55:15 -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 3E283120025 for ; Sun, 4 Aug 2019 03:55:14 -0700 (PDT) Authentication-Results: mail.aegee.org/x74At9TZ018837; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564916111; i=dkim+MSA-tls@aegee.org; r=y; bh=NIx2koRgHyWFHMdDWaxTf6HCZNxuHK9bfvtOJHFYHfo=; h=Subject:From:To:Date:In-Reply-To:References; b=H+HUsqPBnyEPzKFdgYfYXHLz1DpFlJNJmgbdG0qWBuvgeJVLi3GhEfEI7Zk348I+1 FM6PRae8bQAqKEAO8gMZYdnSINcItdlG5UAvQRzDo5racn1UlcJGwf2/ojLaLxEcd2 LuxdMU5DfSQCCHtwY7elsnjsszDSBcf/cDbDAu7eflEHDc7l8JlRonUVO+GnTeLIMc 3Pn/xr5qOeDPn5sPLTQ7LGn4J3lnmO2YoMRQkPdeYpTmqjri2G0B53omCFQ2h8P2sn 5s3/3eEN5K6pWeiqzDo2gJlnEpqQEKRLmcNg0OwzMSGrECNXJnV+8k3CLBQMqajcO4 PEu+brEpKP4kiXeIy0ZUtDcC5XGtuWHnbRWbdKSRWpCvf+r4L83m5dgCFwSsjQ+DOv RJvOxjhhaNO4fzKL6kQAsYmsAiGABDGxUOP26u5hLRVKh8hogySJmYgRiBH4+0TW4h HsXZ8x5KTrpDUnBx3qpLNPPOy9dx4BCgWalSxm7NgCb1SoOzkRw9FVE6nWs68h99fe MBOkCrM0o4f5igHs8PnEb7WUVQ+M0Gw3QwOiJbygUo3saQZHQqC2X9HYS1BDvMU1BW dKSpVGIK9/c5i22c4KJp4IwT7tYrKeeVG+B+OpbOB7/7YHkIaIhIdRpJEzwQgQvuX5 cG/qwGPR8fkcp1vd1iqb2lK8= Authentication-Results: mail.aegee.org/x74At9TZ018837; 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 x74At9TZ018837 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 4 Aug 2019 10:55:10 GMT Message-ID: <3ee01bbba61d357b59237994587d5d8dc70e080d.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: Steve Atkins , dmarc Date: Sun, 04 Aug 2019 10:55:09 +0000 In-Reply-To: References: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> <6FCCAD3E-C2EB-4613-B0C0-148AE3387D21@wordtothewise.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] Concerns for not Sending a Failure 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: Sun, 04 Aug 2019 10:55:17 -0000 On Sun, 2019-08-04 at 10:10 +0000, Дилян Палаузов wrote: > > The mailbox provider has no way of knowing that you sent the mail. If it was authenticated as coming from you this > wouldn't be an issue. > > The receiving server knows, which IP address sent the mail and it knows, to which IP addresses set the failure report > will go. If there is a match in the IP addresses, then the receiving server knows that the one who will get the report > is also the one, who has anyway access to the message. Nope. This does not work for redirected messages. The assumption is that no host (sending spam) is going to forge headers in order to entitle another host to receive failure reports. A mail receiving host can obtain the IP addresses that receive emails for a domain (@a.int). If a message, failing DMARC validation, is either sent from an IP address that receives emails for a domain (MX a.int), or has such an address in its Received: headers, then the receiving site shall not have concerns that the one who would receive the failure report would have anyway access to the message in question. If the above validation of the IP address fails, but the DKIM-Signature contains "ruf=y", this means, that the receiving site can assume, that the writer of the message is willing that a failure report is sent for the message and the receiving site shall not have concern about sending reports. As with the b= tag, when calculating or verifying the signature, the value of the "ruf=" tag (signature value) of that DKIM-Signature header field MUST be treated as though it were an empty string. Or NOT? From nobody Sun Aug 4 03: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 24223120026 for ; Sun, 4 Aug 2019 03:56:12 -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 85th624ZxMYb for ; Sun, 4 Aug 2019 03:56: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 162B2120025 for ; Sun, 4 Aug 2019 03:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564916167; bh=5q9iFJb0gDpmm0VudgOv/czGkcCda9zVP/Mf1cbA+HU=; l=1661; h=To:References:From:Date:In-Reply-To; b=Bnodeu/AOrEOqR7mSLVgGTJZWMOISVFDLhAQdf8JCT8+RV9hAwf9YSkibRivj/a6l HSUAo/r3KGPF6CnD2W31RipQKfC06QYWo+sMfA3Zcj30ern4dRAl0+8/BuDRiqA+dZ iA3WznGLQx+86ylyjGkuZbRiIo3ivrxxrOHANG9d6I2hXh7lTl2D6pTUHMDh7 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC03D.000000005D46B9C7.00001743; Sun, 04 Aug 2019 12:56:07 +0200 To: dmarc@ietf.org References: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> <6FCCAD3E-C2EB-4613-B0C0-148AE3387D21@wordtothewise.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <036af2bc-4c77-af23-376d-1a2ce60e064f@tana.it> Date: Sun, 4 Aug 2019 12:56:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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] Concerns for not Sending a Failure 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: Sun, 04 Aug 2019 10:56:12 -0000 Hi Dilyan, On Sun 04/Aug/2019 12:10:51 +0200 Дилян Палаузов wrote: > The receiving server knows, which IP address sent the mail and it knows, to > which IP addresses set the failure report will go. If there is a match in > the IP addresses, then the receiving server knows that the one who will get > the report is also the one, who has anyway access to the message. That's not always true. For example, I know of mailbox providers who, on delivery, automatically encrypt cleartext messages to the public key of the recipients, including the Sent folder. Operators at that provider's aren't able to sniff message contents unless they're sent back on failure by receiving sites. In general, users trust their mailbox providers also because of the policies they enact. Matching those policies with unwarranted disclosure of messages is not straightforward. In addition, the most interesting reports are messages not coming from my IP. Scammers abusing may domain name use their own IPs. I see those failures in the aggregate reports, but don't know if the IPs mentioned there correspond to mailing lists or other legitimate forwarders, or even some ill-informed users of mine who send their mail through their ISPs. That's why I need failure reports. It would be enough if the aggregate reports contained an indication of the spamminess of those messages, or the reputation of those IPs. Failure reports for messages originating from my IP are only useful for debugging. An activity which I can more easily do by using free mailboxes, as you said, or sites specifically dedicated to testing email. Best Ale -- From nobody Sun Aug 4 04:47:09 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 96BFA120025 for ; Sun, 4 Aug 2019 04:47:07 -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 qhGS2TVaiZlp for ; Sun, 4 Aug 2019 04:47:06 -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 AB407120019 for ; Sun, 4 Aug 2019 04:47:05 -0700 (PDT) Authentication-Results: mail.aegee.org/x74Bl10e029318; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564919223; i=dkim+MSA-tls@aegee.org; r=y; bh=8szj5lN3/sIq1M6uuvPVwihLvylWnPo4eA/X4NkCsAQ=; h=Subject:From:To:Date:In-Reply-To:References; b=qNGWSURcoMdirU/UGy5us9p1qQgQoswttATjmVcy+Be5sEOOvDE7UoeZ5yIrooF9H mDtRpANe1nTivZpTFgTy1PbXSaGIhmzfQ84ZHkq28SoDmW07shxzOVNxjbIIrk0u4L xmA2RiYT+rHA4sISHjrUcngDeem7XkymJBeYEzc+AZfywSku4EhMxlIq7GOqeyBRr3 OJ6pZ74z199BIWawnRY2MmNSmDpeHWPP6x+KCsHTXRhjSOGt6l2y/WUZVGKvHDNq76 LCE1nXoibanigJaSKUcLf2IE2QkV4Cpqvqz8jQAPFkJQnUcWapUVq/aM/5wFx8G1/k vteXO8/XiqUp5xv6yajZo2UMlt0kBi3p4tVjdmALj16Z82MmbR1vnWxXmMoBzhMZGA aOUYXvXLxbt/nJoBNCgL9UR/djl+VWcTrQCi3fC9npP4FPDr1aYP62gGxbelf9sRfo qPOpEIx190IA8QoWA0ODQmcbxcxCmbBW8LRq0yrgJIHGJ/pRa47k8IoFdbfh4PXLj2 3xQsPCFZ2Ke5evrhVqgnWVvTOJrBYNZ3ulyjXSFF3CpgxqKf/8eaVM+DQRrcCQm6lA 5WjJkn0nlmyi1kfEdhq/trzzSIFqPfRiETJ2xkRVPgGFgADvjpZhLd1OOByAlEgg3m LoWBPyLkLEB3AwvAwYZpRE7Y= Authentication-Results: mail.aegee.org/x74Bl10e029318; 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 x74Bl10e029318 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 4 Aug 2019 11:47:02 GMT Message-ID: <9e57756d0099acb3dcf5915e77a38045343d463a.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: Alessandro Vesely , dmarc@ietf.org Date: Sun, 04 Aug 2019 11:47:01 +0000 In-Reply-To: <036af2bc-4c77-af23-376d-1a2ce60e064f@tana.it> References: <5DD2CBA9-6F28-483C-9B08-8D3A41526BD7@wordtothewise.com> <6FCCAD3E-C2EB-4613-B0C0-148AE3387D21@wordtothewise.com> <036af2bc-4c77-af23-376d-1a2ce60e064f@tana.it> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] Concerns for not Sending a Failure 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: Sun, 04 Aug 2019 11:47:08 -0000 Hello Alessandro, what is the purpose of the failure reports? If the purpose is align DKIM, SPF and DNS implementations of senders and receivers, then I am proposing ways to exchange information for debugging. I do not propose how to obtain information about scammers’ actions. DMARC is invented to make the workflow of scammers impossible, it is not about exchanging information of performed scammers’ action. If a site promises to its users, that all emails will be encrypted, then publishing a ruf= address likely violates that promise. This is not necessary true, if the failure report is delivered (encrypted) only to the person who sent the original message. This creates a big fuzz, whether forwarding always the failure reports to the sender of the original message is a good idea and goes out of scope. I changed my mind: The DKIM—Signature has a tag r=y. It is a matter of adding a new value r=a, that means both: • The writer of the message, or a site which has received the message at some moment, is willing that a failure report for failed DKIM validation is sent, for every present DKIM-Signature that aligns to DMARC. The one who adds r=a can have a copy of the message. • Receiving sites can assume, that whoever adds r=a has a already a copy of the message and sending failure report with the content of the email does not reveal information to the recepient of the report about the content of the email. Now, if nearly all mails from a domailn, that pass DMARC have r=a and emails that fail DMARC from the domain, have no r=a, then the lack of r=a on its own, makes the mail suspicious. Will scammers start inserting r=a? Will be there a doubt, when both r=a and ruf= are present, that both the writer of the message and the domain owner are willing to receive failure reports and neither of them has concerns, when the reports are sent? Regards Дилян On Sun, 2019-08-04 at 12:56 +0200, Alessandro Vesely wrote: > Hi Dilyan, > > On Sun 04/Aug/2019 12:10:51 +0200 Дилян Палаузов wrote: > > > The receiving server knows, which IP address sent the mail and it knows, to > > which IP addresses set the failure report will go. If there is a match in > > the IP addresses, then the receiving server knows that the one who will get > > the report is also the one, who has anyway access to the message. > > That's not always true. For example, I know of mailbox providers who, on > delivery, automatically encrypt cleartext messages to the public key of the > recipients, including the Sent folder. Operators at that provider's aren't > able to sniff message contents unless they're sent back on failure by receiving > sites. In general, users trust their mailbox providers also because of the > policies they enact. Matching those policies with unwarranted disclosure of > messages is not straightforward. > > In addition, the most interesting reports are messages not coming from my IP. > Scammers abusing may domain name use their own IPs. I see those failures in > the aggregate reports, but don't know if the IPs mentioned there correspond to > mailing lists or other legitimate forwarders, or even some ill-informed users > of mine who send their mail through their ISPs. That's why I need failure > reports. It would be enough if the aggregate reports contained an indication > of the spamminess of those messages, or the reputation of those IPs. > > Failure reports for messages originating from my IP are only useful for > debugging. An activity which I can more easily do by using free mailboxes, as > you said, or sites specifically dedicated to testing email. > > > Best > Ale From nobody Tue Aug 6 08:11: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 2D0581203AD for ; Tue, 6 Aug 2019 08:11:35 -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=leemankuiper.nl 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 nfu0Yy4558sb for ; Tue, 6 Aug 2019 08:11:33 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 099DE120365 for ; Tue, 6 Aug 2019 08:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ruNoRf0NI2t1VjfI769VovD7munOmDw931TsXnlRjGY=; b=HhZkpQbFNeRaewK4olf8YHdaHK c/lQse+6vjeO8N3n93KPIzYcsfyJ6vizBnfNwkBGBIcaqAJDjNsNGIuXkkmiN2np+AOf8TmESa3gC tJsH9jbmXa28C5XQq3wZaSmrGIRzd/1EtHQ3mpXt6Uh2JGYs8qsKjmvW2IbC6ebao8GsEfTxqX7qs U+TKW7SxTQRouSKUN0Z5YubtFfxdkxdO0Qtrkorokay8GrZFBnKyFXbY4VXprVX98c6cEe4LbLtyx A14ucQz48tXEZCmbRsHORQdDkkmyfu5285W4JRi/T2NueqRTl3/zvYHDsQGbYL3wwcoEN2vQsuufZ KChK2NHQ==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hv17a-0007vS-Nz for dmarc@ietf.org; Tue, 06 Aug 2019 17:11:30 +0200 From: "Freddie Leeman" To: Date: Tue, 6 Aug 2019 17:11:29 +0200 Message-ID: <009c01d54c69$39745520$ac5cff60$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdVMZb+w/9K+Rqz0QAWOGUPx1Dt+Ug== Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: [dmarc-ietf] Should 'undeliverable mail' be included in DMARC rua 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, 06 Aug 2019 15:11:39 -0000 I've noticed that, even though RFC7489 appendix C states that the 'envelope_from' element has a minOccurs of '1', this element is missing quite frequently. This is probably due to the fact that some messages have a 'null reverse-path'. The RFC5321 (Simple Mail Transfer Protocol) chapter 4.5.5 allows a 'null reverse-path' ("<>") to be used for non-delivery notifications, delivery status notifications and message disposition notifications. So what to do? Should messages with a null reverse-path be excluded in DMARC rua reports or should the minOccurs value of the 'envelope_from' element be changed from '1' to '0'? -- Freddie Leeman From nobody Tue Aug 6 10:36: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 E46401205DB for ; Tue, 6 Aug 2019 10:36: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 Gsp9hQ4DrLcu for ; Tue, 6 Aug 2019 10:36: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 9710812028B for ; Tue, 6 Aug 2019 10:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565113003; bh=ncb9TIAOFZ88zpKWA9/a9KBO7M0rbfnTgUywIpNCkV4=; l=1571; h=To:References:From:Date:In-Reply-To; b=BpWBXYwFx+uzs/g0muhhLtqJzhA9kxYzCDIH7FLFhLBGHZXYeaJpqYho+LewQAZjd b9BDhCkUvo3xmNjudBWeHMoLY9Fm3tUEf1m1v1bIl9ei+7KJBwY1M+rVNjxfDNyW0O WQrZ9W19UKIjZQEvSJgTKaRgZD4ddYgT71Gy4BGbBDvQa+AqbMgJ24nH4YO9g Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC042.000000005D49BAAB.0000283F; Tue, 06 Aug 2019 19:36:43 +0200 To: dmarc@ietf.org References: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Tue, 6 Aug 2019 19:36:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies 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, 06 Aug 2019 17:36:48 -0000 On Wed 31/Jul/2019 11:47:29 +0200 Freddie Leeman wrote: > [...] > > DMARC reporting capabilities are a valuable aspect of the DMARC mechanism. It > can help domain owners in setting up and hardening their DKIM/SPF/DMARC policy. > But unless these reports follow strict guidelines they just pile up to a lot of > inconsistent data open to interpretation and guesswork. Domain owners should be > able to understand the data without the need for a spiritual voodoo DMARC guru > (trademark pending) to make sense of it all. I had tried and programmed carefully, but never formally checked what I was sending. Too bad. Now that I did, I see my reports miss the and [*] elements, and some other nuisance. However, the most striking difference is that, after some tinkering, to be able to formally validate a report, it has to be rewritten like so: example.com postmaster@example.com [...] Is that correct? Is that how reports should be written? I ask because checking some aggregate report I received, I found no mention of namespaces and schema locations. XSLT works well even without those. Validation doesn't. What do you reckon? Best Ale -- [*] is present in Appendix C of the spec, but not in https://dmarc.org/dmarc-xml/0.1/rua.xsd From nobody Tue Aug 6 13:24: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 1305212008F for ; Tue, 6 Aug 2019 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, LOTS_OF_MONEY=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WUfX3xwI; dkim=pass (1536-bit key) header.d=taugh.com header.b=KHVuQ0vg 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 eOzKerrZy4-d for ; Tue, 6 Aug 2019 13:24:24 -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 A16E412007A for ; Tue, 6 Aug 2019 13:24:24 -0700 (PDT) Received: (qmail 63052 invoked from network); 6 Aug 2019 20:24:23 -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=f64a.5d49e1f7.k1908; i=printer-iecc.com@submit.iecc.com; bh=H2mNWYOczd6cLvEgP7ypKWgFVUIYoxRZssCi40O6VZg=; b=WUfX3xwINIAgaJPK1D5kztbIW+Z6yXqWuPqKuS2C4nezP0fxUU9mwHM+Hyp9TpDyRaArLSK6JPzP7MWGh+luExy6+fP9M6MaMhMn5wTcnSzp97UK567RdM+l7jwr4u5m91B3iP3wsZ2GgKt+HyHHmkGCpH2//YVzYyWPnsv8QjO2Kyr2ju9J7mZKq/vinXEqcbjW/oGLK7KYN4JXC0azgBeQpyvwTtvIXDlBkf9uitJ0d6fxrcHScphOTjt56A9n 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=f64a.5d49e1f7.k1908; olt=printer-iecc.com@submit.iecc.com; bh=H2mNWYOczd6cLvEgP7ypKWgFVUIYoxRZssCi40O6VZg=; b=KHVuQ0vgQHdui8e2IJeXv3zyv0wHavlUBQKrV97goPqQVwob+qRkH5GdsOlPgDrtLsIJMzv/CeNwy4sAEB5ntEG6E+B+dvffH/ldm1u6v2OYzgMxybaxlDz0wOFP9R9gz4kEW5mBYCtch9KDO+2xZaI/zaHrgOaz2BXJYi2wLTvTgiJSmasS+ZValrrm9gceyfWw6LfyWbPIo5Q2Codg7eU+Q5lTU1Zf8BEyBYCFbbsLFPMKXHBS+zBghdT74pEe 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, printer@iecc.com) via TCP; 06 Aug 2019 20:24:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 26DB77B426F; Tue, 6 Aug 2019 16:24:22 -0400 (EDT) Date: 6 Aug 2019 16:24:22 -0400 Message-Id: <20190806202423.26DB77B426F@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: freddie@leemankuiper.nl In-Reply-To: <009c01d54c69$39745520$ac5cff60$@leemankuiper.nl> 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] Should 'undeliverable mail' be included in DMARC rua 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, 06 Aug 2019 20:24:26 -0000 In article <009c01d54c69$39745520$ac5cff60$@leemankuiper.nl> you write: >I've noticed that, even though RFC7489 appendix C states that the >'envelope_from' element has a minOccurs of '1', this element is missing >quite frequently. It's not missing, it's empty. That's not the same thing. R's, John From nobody Tue Aug 6 15:06:05 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 3DED8120289 for ; Tue, 6 Aug 2019 15:05: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, 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=leemankuiper.nl 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 SUkXKylwPCRS for ; Tue, 6 Aug 2019 15:05:56 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 364071200BA for ; Tue, 6 Aug 2019 15:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nL7eEfV2+KSK6K4Pq2z+YKURPxrcycCEvIUfusLbg9Q=; b=k/HVGO9BSELoRu0qih41C4CMNx iP1DCquN1px32CKnsuWqC0Yims3Yw2Gn0CR30ztltzPnlIBH2TGEqnDumd7652u9mj/MgNZNMpvVR XTjAuSHAZKkJGuofv5odNmtSLl4kBB83f7nwO4Ro+g6N6tZyfB0Gs/ufUwN7d438EkQykMiN6qPXL X08+VNFyVDVjfepU9oAIzfmvhrcVfLZHK3jl9piMECz/D3KL6vtIe9nHlMFKFQiXwp3CXQvyhod3p vYou5ifTEKRhgvykoq9rN4wZr/FEIU3hBrsaYcefxsu68STzBHfHzDO4ua3/FyUXnIq9epLbT8HpT bjAck9hQ==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hv7ac-0007Ac-27; Wed, 07 Aug 2019 00:05:54 +0200 From: "Freddie Leeman" To: "'Alessandro Vesely'" , References: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> In-Reply-To: Date: Wed, 7 Aug 2019 00:05:52 +0200 Message-ID: <00b101d54ca3$1d388040$57a980c0$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEwMtDJj/TREh0OevgSswABly9FJAFy9+IqqC1FHHA= Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies 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, 06 Aug 2019 22:06:04 -0000 Great!... more inconsistencies. The xsd file does not make things better. It also does not mention 'envelope_from', spf scope, and parent version. I understand now why so many organizations have a different implementation of DMARC aggregate reporting. I think we can all agree this is a mess we need to fix. I don't believe the namespaces and schema locations are the biggest issues but the RFC should be clear about that to. Thanks for bringing the xsd to my attention. -- Freddie Leeman -----Oorspronkelijk bericht----- Van: Alessandro Vesely [mailto:vesely@tana.it] Verzonden: dinsdag 6 augustus 2019 19:37 Aan: dmarc@ietf.org Onderwerp: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies On Wed 31/Jul/2019 11:47:29 +0200 Freddie Leeman wrote: > [...] > > DMARC reporting capabilities are a valuable aspect of the DMARC > mechanism. It can help domain owners in setting up and hardening their DKIM/SPF/DMARC policy. > But unless these reports follow strict guidelines they just pile up to > a lot of inconsistent data open to interpretation and guesswork. > Domain owners should be able to understand the data without the need > for a spiritual voodoo DMARC guru (trademark pending) to make sense of it all. I had tried and programmed carefully, but never formally checked what I was sending. Too bad. Now that I did, I see my reports miss the and [*] elements, and some other nuisance. However, the most striking difference is that, after some tinkering, to be able to formally validate a report, it has to be rewritten like so: example.com postmaster@example.com [...] Is that correct? Is that how reports should be written? I ask because checking some aggregate report I received, I found no mention of namespaces and schema locations. XSLT works well even without those. Validation doesn't. What do you reckon? Best Ale -- [*] is present in Appendix C of the spec, but not in https://dmarc.org/dmarc-xml/0.1/rua.xsd From nobody Tue Aug 6 15:08: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 D733712008B for ; Tue, 6 Aug 2019 15:08: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, LOTS_OF_MONEY=0.001, 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=leemankuiper.nl 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 WhZtEb9G_qXH for ; Tue, 6 Aug 2019 15:08:04 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 3A91912006E for ; Tue, 6 Aug 2019 15:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FpzCXuCHA0a/exPaGaY47BLJ72zFVZ0JMuFlxkGRwnw=; b=ZFvPCR+EEv10qb7l9yIbTWO8cZ X/2s/fr9HwTJjIjQGZwfJ3EbJsRCw+0Mir9Ik6A5lHCWermhR375fsvV/+snfnJS4YsiAsTWqbqUL esbH15OWefzTbEvxl/0qDFhrk3zTXtl14u1opqMhgKVT66EjGPufXy11Q03Yv1Inz6T2jLXePNrC2 +Ycs80ZTTDavWQKuVgzCoXhxj43oeNAiqPqj0i5nzNj0dElDmvm8gJMeXr2quo2XW9WBtcJm/dHAs zdsuI2X0F0E6vCtP2JmSghRLDvGY33WscBUvunWo/ZML1M1050CfLfd5DZ2AVEtQzlRdxZN8sakXa JpooTttQ==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hv7cg-0007Di-SK for dmarc@ietf.org; Wed, 07 Aug 2019 00:08:02 +0200 From: "Freddie Leeman" To: Date: Wed, 7 Aug 2019 00:08:01 +0200 Message-ID: <00ba01d54ca3$69ffce10$3dff6a30$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdVMo19P9yM3YqgRRCCBo5V9iPTfBw== Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: Re: [dmarc-ietf] Should 'undeliverable mail' be included in DMARC rua 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, 06 Aug 2019 22:08:06 -0000 Thanks for you input John. I know the difference between missing and = empty. Most (larger) organizations omit the element completely = (zoho.com, google.com, linkedin.com, mail.ru, comcast.net, Yahoo! Inc.). = Only 34 percent of all DMARC report generating organizations publish = reports with an empty envelope_from (stats based on last 7 days). If we agree that messages with a 'null reverse-path' should be included = in reports, than Appendix C should state that this element is mandatory = but can be empty. Another solution would be to allow the element to be = omitted, saving bytes (personal preference). Are these non-delivery = notifications, delivery status notifications and message disposition = notifications useful in DMARC reports? If so, than we have to agree on = how to report these messages and make the appendix clearer so that there = can be no misinterpretation. -- Freddie Leeman -----Oorspronkelijk bericht----- Van: John Levine [mailto:johnl@taugh.com] Verzonden: dinsdag 6 augustus 2019 22:24 Aan: dmarc@ietf.org CC: freddie@leemankuiper.nl Onderwerp: Re: [dmarc-ietf] Should 'undeliverable mail' be included in = DMARC rua reports? In article <009c01d54c69$39745520$ac5cff60$@leemankuiper.nl> you write: >I've noticed that, even though RFC7489 appendix C states that the=20 >'envelope_from' element has a minOccurs of '1', this element is missing = >quite frequently. It's not missing, it's empty. That's not the same thing. R's, John From nobody Wed Aug 7 06: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 3311F120052 for ; Wed, 7 Aug 2019 06:46:42 -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 (2048-bit key) header.d=leemankuiper.nl 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 pyoVjcIvQtXe for ; Wed, 7 Aug 2019 06:46:39 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 5911612004F for ; Wed, 7 Aug 2019 06:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3zeeGBmQ0ixWIfnUhQbPxp/QqAPuTxNckAmbJW57YHg=; b=OBc/d6CQeUYnFv1Fzgo4E0vpeK xK3Kh79mfGvUduXwttCeA9TZuXNuJ3Mo1tFbYFfBO7rCgI8q2udcX8mdTBS2qtzVbPoafmzQPM0XR 21/3lOUswi+26CtEgs2063P6kmEUEKwpKIqjmUiRv/lyQDBFP6IwZjQ2ULVt+Ozi64hD4RL8TGgjw Zso9oas8oAJIwN5qEg9rsBQYpcprQ9pTdb5e4LELidFjB9zW55mK1GGI4L3jKRaVr+lDgWKeOfAzg qcNv94INJ1AKsi8i7LzeTgHA/FDIetqomfczC6iV61i/42UBsU91zlzX1cDje97s+WO4EjM2z5qxw 4EsutgXA==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hvMGz-0001Vj-1W for dmarc@ietf.org; Wed, 07 Aug 2019 15:46:37 +0200 From: "Freddie Leeman" To: Date: Wed, 7 Aug 2019 15:46:35 +0200 Message-ID: <016301d54d26$88020f30$98062d90$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdVNJmrh9xRmS+tgRvOQJui8GP3LbQ== Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: [dmarc-ietf] Missing report elements and dmarc.org information based on deprecated drafs 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, 07 Aug 2019 13:46:42 -0000 I've been digging through the DMARC pre-IETF drafts and IETF drafts and = came to the following conclusion: The following report elements were added to (pre IETF) = draft-dmarc-base-00-03 (January 2013) [1]: * IdentifierType 'envelope_from' * SPFAuthResultType 'scope' * DKIMAuthResultType 'selector' * feedback 'version' The following report elements were added to IETF = draft-kucherawy-dmarc-base-02 (December 2013) [2]: * PolicyPublishedType 'fo' I went through the data from the largest suppliers of DMARC aggregate = reports in the last 7 days, and came to the disappointing conclusion = that emailsrvr.com, google.com, linkedin.com, Yahoo! Inc., and zoho.com = NEVER publish the above elements in their DMARC aggregate reports. It looks like most DMARC report sending organizations (even the DMARC = founding contributors like Google, Yahoo! And LinkedIn) based their code = on the pre 2013 drafts and haven't touched that code since. This = explains why XML elements are missing from their reports and report = validation fails. You would expect that as soon as the RFC was published = in March 2015, the organizations would have updated to the final XML = schema, but unfortunately most didn't. What surprises me even more is = that the site dmarc.org holds information and examples that are also = based on the deprecated first drafts [3,4].=20 If we can't even publish reliable information on the dmarc.org website = and get founding contributors to follow the DMARC RFC guidelines, I = think DMARC will not become the reliable standard it should be. I've = been in contact with most (large) organizations that fail validation but = so far only Comcast has been willing to listen and fix their DMARC = reporting.=20 [1] https://dmarc.org/draft-dmarc-base-00-03.txt [2] https://tools.ietf.org/html/draft-kucherawy-dmarc-base-02 [3] https://dmarc.org/wiki/FAQ#receivers (I need to implement aggregate = reports, what do they look like?) [4] https://dmarc.org/dmarc-xml/0.1/rua.xsd -- Freddie Leeman From nobody Wed Aug 7 08:13: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 D5CD9120336 for ; Wed, 7 Aug 2019 08: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 wb7zHTt0dDh8 for ; Wed, 7 Aug 2019 08:13:35 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 DDC53120325 for ; Wed, 7 Aug 2019 08:13:34 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id p17so85855510ljg.1 for ; Wed, 07 Aug 2019 08: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=hBmBzwuTyYmzlfirBEdTAg01cgWC61Px+WUD8pWcK98=; b=WChJJyO5tPDbn2CGKMDV+mhXNMEd4+05Kp3Z/B+/ajcr2lUXvCR1fdrqFUotisTond RjhT6wlQaLC0FGD8e++rwPADCR6w6FyI02egtaTvZtBGTaGnpTU6GhCV3Zr0ecvS/jCU qaHZydJZ7BhwZpHAPDTpn125oxSosQcn6ECpOFGdiGOLMkSCPYtHzEVPeQimsaTvY+We WlOdA4IP/m/Pl0BP4Aws/Dp2mVPVzjObcmbaj3b9dZ+43kmC0Z2UEjhVovLUJ3cP3fcQ Up0IiKgaiS/OXJeSe2yItDgCGQL8iTIDp9lDQ2Wt1EQKz/DXCyakSV1ePeCmKLhGd3c7 FWNg== 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=hBmBzwuTyYmzlfirBEdTAg01cgWC61Px+WUD8pWcK98=; b=q3FYo/kKqa56B4kGhGlO1BT2L+HZysTQyiyttLeCYisyqsZi8GzNtnJYbSteEczYQm R+K0SvAC2UHyVUrq8UNKWH9LlHPN6znWJNgF+9m6Qdkry3liMPV+27Ly8JTqkKSIpKCQ E3d9d7iEqlUJY4qZCP26tnLWvg0NwHI9thzS49/p0e6XBCK8pZtiftyIG+1g8LIgn5A9 D4Y3ZD4hCzLJReYseCPUcbaZfjscM7pCYe4t9VlKe2kYYu9ZYFRfqpDINL2Y2arBmzEK DSc05LxTXkfphBddK5emLlwmR0XD+jSUiTu+8S43ms4lzMEn5SBVmb011cF3fCZ24/zV Vq4Q== X-Gm-Message-State: APjAAAXzs7fe0QwmkTultXEQBIiU7W+Fu1xJAeulHo5FIXDkrmDSJHZd 7PHlBWBNlOiTS4lbPptPzOFDkSBi1MuE7x2JHJKyGQ== X-Google-Smtp-Source: APXvYqxOFbkHVjWAxOFBxDY1HCA9csxI4CIPcXunudjgoz+SgPkkRwZLlwj3ohCnz57eSxqAmh13r6ol2nLXvz2OO3U= X-Received: by 2002:a2e:988b:: with SMTP id b11mr5175921ljj.110.1565190812955; Wed, 07 Aug 2019 08:13:32 -0700 (PDT) MIME-Version: 1.0 References: <20190803030532.1D33375D900@ary.qy> <0CB7D475-6DDE-403D-BA65-E38C89A6D90A@kitterman.com> In-Reply-To: <0CB7D475-6DDE-403D-BA65-E38C89A6D90A@kitterman.com> From: "Murray S. Kucherawy" Date: Wed, 7 Aug 2019 08:13:18 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000069787f058f886252" Archived-At: Subject: Re: [dmarc-ietf] New proposed wording for p=quarantiine 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, 07 Aug 2019 15:13:37 -0000 --00000000000069787f058f886252 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman wrote: > Policy is an indication of sender preference, not a directive the receiver > must follow. I think the definition is fine. If the sender prefers > failing messages be quarantined, then they should use that policy. They > won't get what they want in all cases and that's fine. > This matches my understanding. -MSK --00000000000069787f058f886252 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 3, 2019 at 12:02 AM Scott Kit= terman <sklist@kitterman.com= > wrote:
Policy is an indication of sender preference, not a = directive the receiver must follow.=C2=A0 I think the definition is fine.= =C2=A0 If the sender prefers failing messages be quarantined, then they sho= uld use that policy.=C2=A0 They won't get what they want in all cases a= nd that's fine.

This matches my und= erstanding.

-MSK
--00000000000069787f058f886252-- From nobody Wed Aug 7 08:14: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 1CE7212012D for ; Wed, 7 Aug 2019 08:14:39 -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 Gw5FvwpBEr_j for ; Wed, 7 Aug 2019 08:14:37 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 10E79120224 for ; Wed, 7 Aug 2019 08:14:37 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id v18so85774932ljh.6 for ; Wed, 07 Aug 2019 08:14:36 -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=mUU6rYMrNzQ43OMQDg0nLGtJmG/ikU5w/NdZe4ESbCE=; b=t3OV4htz9vmazh+A5XMZ8aVihrBve+BRijB0XP8PChpd1p5rdbOPSDk83aj8h4w591 N3CfC1QOffy3DlUeqwHc1txxWYDp7hfZBuj05JbO9A4rhZKsv0rYYlJih1xSFa7GNo5T z+MnywehNx+25s6NbsCRI1wnI7BCApnZmgnprBdpvJWg8/FC9zObKJ8kdKTZDp13xgrV Vmi+QlcWhue3s+hnpmBuwmdX07UmAk8lxvtiVVsp62yMBniunM1Ww8S1Wv4rUqR3sLIV s8lBvN6fPJBtajm2ZMWnt+rcbvrXXvQmSr6y6jaNKSZaT0x9gtRwOWv9KI4rBcNVTTsy s6XA== 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=mUU6rYMrNzQ43OMQDg0nLGtJmG/ikU5w/NdZe4ESbCE=; b=EXWHM6WbVftkLpkWAm/Zh24TeRy7OOj82oiUyWquDJ/muDSTi/SAFp8/DLF6orwN6K mEEe6DDAyTZxSujQ2bYoXj202oHMd1Ll9FoVvD5yZEUdxVqfdRm7gUVhIl37U95Bk2Ea Qtn7CMEWWJ6Zep/m9RR0I9dDlqtHN8RCJJmGbgB4u948Pgjg2B0AM9RJO1iGv25VsQmh PVkY5yd0SFnapVhCFJ0zK8ObZvP6xFIPRv7dQCRySjBxDMjC++D+I99qbMwwKIKQ067c qdF4yGldNQJb66OCFsEpOUvDmX+C796jpcgAY6t8ZLfIHBzd1OHQ1lnr291/KvYXFlUg 69Yw== X-Gm-Message-State: APjAAAXYPtnpzkB0LlK1QLBOnMC4VCPFHnk7BHmRcE1DhF4OD+G4vdJw nBlrIoVJig+mGJeTNrlVBXYz4B/X87Ugfk9gFwsjHQ== X-Google-Smtp-Source: APXvYqyUdYGJfcpO5QE7yVNjsWXvN4SvJCQRgIyvpdcyNjU5Qklorx00+QCn3KufieJ/Q+u7TN2iN4yylaEAIGAGzZ0= X-Received: by 2002:a2e:7c14:: with SMTP id x20mr3105615ljc.56.1565190875239; Wed, 07 Aug 2019 08:14:35 -0700 (PDT) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 7 Aug 2019 08:14:22 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001fda0d058f886670" Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 15:14:39 -0000 --0000000000001fda0d058f886670 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 3, 2019 at 8:28 AM Alessandro Vesely wrote: > IOW, dnswl=pass means the sender was whitelisted. > If that's the case, why do downstream agents need "policy.ip" at all? -MSK --0000000000001fda0d058f886670 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 3, 2019 at 8:28 AM Alessandro= Vesely <vesely@tana.it> wrote:=
IOW, dnswl=3Dpass means the sender was whitelisted.

If that's the case, why do downstream agents n= eed "policy.ip" at all?

-MSK
--0000000000001fda0d058f886670-- From nobody Wed Aug 7 08:17: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 7670B120374 for ; Wed, 7 Aug 2019 08:16:49 -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 2Yrj2Tb6OQOZ for ; Wed, 7 Aug 2019 08:16:47 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E042A1203F8 for ; Wed, 7 Aug 2019 08:16:43 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id x3so64432511lfc.0 for ; Wed, 07 Aug 2019 08:16:43 -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=cvpSLw8V1rwUXDeSwStB4oYZwOXl1H29C58CCcAw/HY=; b=ED+tzuKw/QQSgDm/RkTf/8dADTM47ao9kwAyHrkNjGCfAHysD/nr5a9iwNlsJ7U45F vcpQLcdO1KtYXXCWvB1mWCdD1WdWxQiSDVUgwj2Tba+YHdstV5CV8zfeX9Ne/9fZRiEQ QfoOw1gxoBNYN2q2Oe1CjlQgF6yfHN3JF1pcp7P+EjN3dMadXSTobcIJMevM7A2E5l/T XgDzFVp+MqXvu6laK+sQH0kTdhhULiFY2aJVwqabt7xOa2wlwHUFg9Oha3orcg+1bx6T m0v7cbEdxQFQq/4rdE+zLVWWASWTNAbwM25tOpFmK7A2lgb6R+HVJ+8SXICkJ518s7ia U41Q== 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=cvpSLw8V1rwUXDeSwStB4oYZwOXl1H29C58CCcAw/HY=; b=K2NVT4Y61KruqtTJrQ7t01PbEcKAHLU9s8q2+1Ni7vVHPUQRtx8MPFi8DjlhWsJeMq DBzKl/vL9MH8TyJtijmClR/NZVKs1dlvx97Vl91Bftpdduu6XMQ20fgDWYORpooS1aig hFKVWYpK2gfSkP6I+pN+m3z8K11csfE1NAF/wPiZhlpo6fxkK6ZLRUKsXEu+5DzHKGdO UQ+u1Lm02Ycyxb4MN/cbSOISDOgnHh46R/yFY/LP14oi7d7Z3ja0lr+jrTN4G7MIpY1u g1S5MkenBBsIKkEvM619Zz8Slm5zCHrz4Ou8aC2o5ArOGE66YSWeUNclZU2Rr3PED0S7 IXyw== X-Gm-Message-State: APjAAAXhlY0RZI+8dGSLWGnishcm23fsUhnjeDGqX0TrBO+Y4nzBy/Rv RHyECNJFmiea8tgsWF8a3//dzsKzaxpRDQ2k8kAVsg== X-Google-Smtp-Source: APXvYqwV1ag+TTWZBqGNtbwurap+6hk17MxPyzVUw5TILALpXDo0r1Gef3cR5gipQSys1NYt6JibEPcEMR4DMz2KBZo= X-Received: by 2002:a05:6512:288:: with SMTP id j8mr6698564lfp.181.1565191002078; Wed, 07 Aug 2019 08:16:42 -0700 (PDT) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 7 Aug 2019 08:16:29 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000af400d058f886d5b" Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 15:16:50 -0000 --000000000000af400d058f886d5b Content-Type: text/plain; charset="UTF-8" On Sat, Aug 3, 2019 at 8:40 AM Alessandro Vesely wrote: > That's much better. If the definition of ptype smtp were "a parameter of > the > SMTP session used to relay the message" it would be perfect. I'd propose > that > policy.iprev be deprecated and smtp.remote-ip used instead. > Given that RFC8601 was published just last month, it'll probably be a while before this happens. -MSK --000000000000af400d058f886d5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 3, 2019 at 8:40 AM Alessandro= Vesely <vesely@tana.it> wrote:=
That's much better.=C2=A0 If the definition of ptype smtp w= ere "a parameter of the
SMTP session used to relay the message" it would be perfect.=C2=A0 I&#= 39;d propose that
policy.iprev be deprecated and smtp.remote-ip used instead.

Given that RFC8601 was published just last month, it&#= 39;ll probably be a while before this happens.

-MS= K
--000000000000af400d058f886d5b-- From nobody Wed Aug 7 08:31: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 E9E641203E3 for ; Wed, 7 Aug 2019 08:31:28 -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 (2048-bit key) header.d=leemankuiper.nl 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 A7jKB3dm7Jtf for ; Wed, 7 Aug 2019 08:31:25 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 D59771203CC for ; Wed, 7 Aug 2019 08:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4t+0uzHsGsHik5awIEldJolfEtS/wdjhZHRDD3esRgc=; b=e+1apNz+3K+SA46i6Cz0a+7Qt+ 8SpZ2F8eeuEtwMcBde5azFS4b/5of0Z19tU/AnQF75LUFN4b2Mx9Kt1MyJW0MS/ENUHknT/yctcaW jyp9l5yrNu2Kq70pLXPiDPzxIKA+pWBv8MtxzbGc8I3lEVvCzFAJYf3Q1S5jzCgK7irltp8U8Rsl2 +WGvJ/nTNi9XbWqtrSoJye3VDV1wQt6pLin52dSKJJ2JToVoKgjgwEdbpoQLKI8PacEX656mYxZQd PC+A7S3a2x5VqiwxwfHVJoAc8yhABxTB/40H1HV1TNn6tni7f+1Tf7orU3/A1POEUjI3SmMMJi8FZ 4mVrhwxg==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hvNuM-0003dR-C3; Wed, 07 Aug 2019 17:31:22 +0200 From: "Freddie Leeman" To: "'Dotzero'" , =?UTF-8?B?J9CU0LjQu9GP0L0g0J/QsNC70LDRg9C30L7Qsic=?= Cc: "'IETF DMARC WG'" References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> In-Reply-To: Date: Wed, 7 Aug 2019 17:31:21 +0200 Message-ID: <018e01d54d35$2a603050$7f2090f0$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJIu0T9j5Gm574QYreI9/dffuh59gHbOLplAhC8NysA7c3suQMM09lzAdTQYYuluxh1sA== Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 07 Aug 2019 15:31:32 -0000 I agree that messages with both DKIM and SPF pass results can be useful = when it comes to validating that everything is (still) in working order. = But I come across domains with very high email volumes. So daily reports = contain thousands of records that are consuming bandwidth, storage and = processing power and in most cases aren't looked at (except for a count = maybe). What could be the best of both worlds would be to add a = =E2=80=98success_fraction=E2=80=99 tag that allows a domain owner to = specify a fraction between 0 and 1 (1 being the default) just like = https://www.w3.org/TR/network-error-logging/#the-success_fraction-member.= I would still receive success reports but a 0.0001 fraction for = instance. That will still allow me to detect fluctuation and changes = while limiting the amount of records drastically. This would even allow = domain owners to block success reports completely by setting a fraction = of 0. Your thoughts? =20 Van: Dotzero [mailto:dotzero@gmail.com] Verzonden: donderdag 1 augustus 2019 00:22 Aan: =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 = CC: Freddie Leeman ; IETF DMARC WG = Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' Having both passes and failures is incredibly useful. The percentage of = failures is very useful. Any set of mail streams will always have some = failures. Once you know what the baseline rate for a (sub)domain is, = simply seeing changes in that rate will help you identify problems.. An = increase in the failure rate is generally either 1) someone trying to = abuse your domain name; or 2) something has gone wrong with DKIM signing = or someone associated with the domain organization has started sending = mail from somewhere without appropriate SPF or DKIM. Michael Hammer On Wed, Jul 31, 2019 at 5:24 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 Fredie, DMARC limits the amount of servers that can generate emails for a = particular domain. The aggregate reports show to which extend DMARC = does work correctly and when it fails for a domain. The aggregate = reports to not tell you how to fix your DKIM implementation, so that = sender and receiver agree on the DKIM signature. The per message = failure reports tell you which messages were not signed correctly, so = that you can check the DKIM implementation. I thought some hours ago it could be useful to reduce the amount of = reports, by not sending a report when things are 100% correct, but now I = am not so sure. The aggregate reports contain information, if something is not working = correctly, but they also prove, if everything is running correctly. If = there is an option to reduce the reports to contain only information = about failures, you don=E2=80=99t have a prove, that everything is = working correctly. Let=E2=80=99s say if you write a message to site S = and don=E2=80=99t get an aggregate report back, this can mean, that = DMARC passed, but it can also mean, that S does not evaluate DMARC or = that DMARC failed and S does not send aggregate reports. Is the lack of = success-reports a prove of correctness or not? I am inclined. What do you want to do with the information about failures from the = DMARC aggregate reports? Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote: > Hi =D0=94=D0=B8=D0=BB=D1=8F=D0=BD, > =20 > Thanks for your input and feedback. Maybe a single tag, that allows = the domain owner to avoid receiving aggregate reports for messages that = align, would be enough? I personally have little experience with mailing = lists which, I understand, can be a real pain when it comes to SPF/DKIM. = So would a tag that instructs the receiving party to only send an = aggregate report whenever the DMARC policies is applied be a better = option? > =20 > Kind regards, > Freddie > =20 > Van: =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 = [mailto:dilyan.palauzov@aegee.org] > Verzonden: woensdag 31 juli 2019 17:29 > Aan: dmarc@ietf.org > Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' > =20 > Hello Freddie, >=20 > if a message has 5 DKIM-Signatures, some of them fail DKIM validation = and some of them do not align, irrespective of validation status, you = want to receive a report for the failed DKIM signatures. The proposed = option d is in the DKIM domain. DMARC without alignment is DKIM or SPF. = To get a report for failed DKIM signature you put in the DKIM-Signature = header r=3Dy. After the mail passes over a mailing list, the signature = is invalidated and you get a useless report. Your intension is to limit = the amount of useless reports, but this particular option goes in the = opposite direction. >=20 > If you remove the SPF records and ensure that each leaving message is = signed, you do not need the ao=3D1 option, as each report on failure = will be about DKIM. >=20 > With ao=3Ds whenever a mail is sent to an alias and redirected to = another server, you will get a useless report. I am not exactly sure, = but I think SPF contained some reporting mechanisms, so this option = might duplicate them. >=20 > Perhaps you want to propose a mechanism, that hides the successful = deliveries (useless report) and only reports problematic cases? >=20 > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD >=20 >=20 > On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman = wrote: > > Would it be useful to add an =E2=80=98ao=E2=80=99 tag name for = aggregate reporting options? Something like: > > =20 > > ao: Aggregate reporting options (plain-text; OPTIONAL; = default is "0"). > > Provides requested options for generation of aggregate reports. This = tag's content MUST be ignored if a "rua" tag is not specified. The value = of this tag is a colon-separated list of characters that indicate = aggregate reporting options as follows: > > =20 > > 0: Generate a DMARC aggregate report for every message, regardless = of its alignment. > > 1: Generate a DMARC aggregate report if any underlying = authentication mechanism produced something other than an aligned "pass" = result. > > d: Generate a DMARC aggregate report if the message had a signature = that failed evaluation, regardless of its alignment. > > s: Generate a DMARC aggregate report if the message failed SPF = evaluation, regardless of its alignment. > > =20 > > This would allow domain owners to save on tons of reports to be = handled and processing that are useless in most scenarios. For instance, = when I=E2=80=99ve deployed my SPF/DKIM/DMARC policy and I=E2=80=99m = pleased with my policie=E2=80=99s results, I would still want to use the = reporting to detect and fix changes in my email environment. If a = million mails a day are nicely processed with DKIM and SPF aligned, I do = not need those entries in my aggregate reports. I=E2=80=99m only = interested in the reports where either DKIM or SPF fails. In most = scenario=E2=80=99s this will cut data transfer and report processing = with more than 99 percent. Whenever there is a bump in the number of = reports received, I can detect that something is wrong and I might need = to add a host to my SPF policy or need to fix my DKIM signing. > > =20 > > I was amazed that these options weren=E2=80=99t in the current RFC, = as these do exist for failure reports. Am I missing something? Is there = a reason why this would be a bad idea? > > =20 > > Kind regards, > > Freddie >=20 > _______________________________________________ > 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 Wed Aug 7 08:55: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 5E5D3120445 for ; Wed, 7 Aug 2019 08:55:13 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcfMrpdYgkcY for ; Wed, 7 Aug 2019 08:55:10 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 85C7B12042F for ; Wed, 7 Aug 2019 08:55:08 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id t28so85965477lje.9 for ; Wed, 07 Aug 2019 08:55:08 -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=B6cipz3Awm872bPOTcktpR/ugSOGZppyctJHuVnGbDY=; b=Oc7048JXP0dv+01PtpsgngQkzUb3rEuHVOXlcjYBPeQejrMPP/VsY/Q+UcFVekN1iA 17fySAIesOoYU76buGOc19LaoJAV8EQOFzhddWKmkgV1WasosFBupmSBSHdKHl/y7eOA 60nmjGPaiKa0AlaD1lcFZp3r0NKZC8K0iwAunvpOhIQ7mppFxTeBDFszS5I6P8nGUDkb 3rEIy8mqIpt1BcZ+dpJwAIku+Iuphq8QfA1naTJ2A3VljVbpJju7C8uvrbCa0KuxAvj/ ezA4UbGefxq3NrWgpiZAgSEQdlIzpRhYifO4egfm9EodgSkt8sNvPZlgsCzeNexB9aaa luJA== 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=B6cipz3Awm872bPOTcktpR/ugSOGZppyctJHuVnGbDY=; b=GJn5QSWUw1ZGtiK2wT22LZcO4VD45ZYMDwfruy+RGhmA1HNbf6mfbE9v3mzyvUBya5 5XmsoxoQn+q1TOZSAazSjVkc4PBe/KK6JHdodYFEaJGlCIv/2rzz1ASdp8I1aogZrmaf 9iskOrs4RgvwHxQfm+V1HpS2DRHlKIFv4yGBjHG1w/G6czeiKldhHCgEGmBmzVmdEIFL hpHhldowuL+RqdesNtRmg5HPrxGea2d2aUgs1g/ItqM3ss8AfV7yLRq+qZBK7awipnLe edVDL//7wOKGAmdnHwO0ak2hWvslK0fAm3lKUdG6XMDEDT6w5iTOnSzzsNYETPoe0WrP eing== X-Gm-Message-State: APjAAAWt/XgzLYQRvXyEzIpinwTlnqzlH55ds0CS7UYsaiDRURuEk+1q Xh0jxIaSqaDs6AVO5REMVyel42iaxmr/R/mcvAc= X-Google-Smtp-Source: APXvYqzUGO1VaY6KxqjKQ+LUckwDiG9fiCla8peGHpzfted3Cc2u+wUiBC3t3ZUhN1Q5q/F3sxzkheiMzVGuJU/Baxg= X-Received: by 2002:a2e:870f:: with SMTP id m15mr5276446lji.223.1565193306629; Wed, 07 Aug 2019 08:55:06 -0700 (PDT) MIME-Version: 1.0 References: <016301d54d26$88020f30$98062d90$@leemankuiper.nl> In-Reply-To: <016301d54d26$88020f30$98062d90$@leemankuiper.nl> From: "Murray S. Kucherawy" Date: Wed, 7 Aug 2019 08:54:53 -0700 Message-ID: To: Freddie Leeman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000be9e9058f88f700" Archived-At: Subject: Re: [dmarc-ietf] Missing report elements and dmarc.org information based on deprecated drafs 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, 07 Aug 2019 15:55:14 -0000 --0000000000000be9e9058f88f700 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 7, 2019 at 6:46 AM Freddie Leeman wrote: > I've been digging through the DMARC pre-IETF drafts and IETF drafts and > came to the following conclusion: > Seems to me the working group has a choice to make here, somewhere between "reinforce the XML specification as published" and "take the consensus of what's implemented and publish that as the revised standard". Either way, this should certainly be a work item for standards track DMARC. -MSK --0000000000000be9e9058f88f700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 7, 2019 at 6:46 AM Freddie Le= eman <freddie=3D40le= emankuiper.nl@dmarc.ietf.org> wrote:
I've been diggin= g through the DMARC pre-IETF drafts and IETF drafts and came to the followi= ng conclusion:

Seems to me the working = group has a choice to make here, somewhere between "reinforce the XML = specification as published" and "take the consensus of what's= implemented and publish that as the revised standard".=C2=A0 Either w= ay, this should certainly be a work item for standards track DMARC.

-MSK
--0000000000000be9e9058f88f700-- From nobody Wed Aug 7 14:15: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 851E3120059 for ; Wed, 7 Aug 2019 14:15:31 -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 knxP_CyTCW44 for ; Wed, 7 Aug 2019 14:15:29 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 BBD0612003F for ; Wed, 7 Aug 2019 14:15:29 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id z23so1817830ote.13 for ; Wed, 07 Aug 2019 14:15:29 -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; bh=4mz32AYgg/tYUJnp+S3QKAT9FJ10hwv14RqBviPg1ug=; b=QN03I9ipOcIRxYwvm+TtJ0TItIPdPm0xpZJEP0oqZn0ad7A4zC9edAqo3InJpgD60T qj2jxdp+WHfeySlGepAeUZXL4iVv+zO66h3SKp1KTawSnhgMM/7WDTmztCNSWj+z/ZZE 8Z87da8YwCC8wiKfx4mwYeVZJPCUJ7I/PfyVt8B1I3LjcPAcczrTyGRmx61NGzEZXkrg LGyMht1oDGcNiSj96XRQs+oOlI7SlkS/8/H0ufZS+m1Y4IsQ1VkilRrvBs3cmPcRFZPO Rioj2svM2oVpWpDcm6Mg7HZQDM9a6e+lWRfx1KXRYymf20J80w+/6r6keDDlGPBPIUA8 E5yQ== 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=4mz32AYgg/tYUJnp+S3QKAT9FJ10hwv14RqBviPg1ug=; b=bqUs7EHsxflIcnzpDi5SMnylojMEzQnfX84DYJ0SEja7Th/cifX5KfarAc1TH04dm0 V7Wi1eKE4Qw78ekuSbiFapvUVS5pfDys/7DvhwudKzyCAUdAMR456eW4KnE/bszhB8PF 9q6hr3c1UC6Zk+QzPdMRLmdtWy+eQ4DxPQYfXOxi5TWXz6Q8I/qsMBqTXycukdOnIvWo +wrGfYFXchQIRKLXUPm/ByVOUZQn0YnuOZ6at0HFm+6d3WmNNkvHqt65NF2Q9wXCPpJg xYyWb3aTh9P0i2uhE4kmBLnauoZ7hRPNxO0Yfedt25No0veSX+Ts6x6Op6eGqsU2DYIV mT8g== X-Gm-Message-State: APjAAAXyp3kvLIhuxKBuJq794puIqzLkaSel7dT+d++NvrOyr8wKkYiM icIXwYWSKyppryj3Uo1ZKapFJll6dybl/CNk9ya3qKFM X-Google-Smtp-Source: APXvYqyY7DYWAcq02GoKkztN0pGIlilWxcR4ozwVCa04rUNxoLTK6O251yAZV6+O4RRuVmuy+SU9c5nXpvBl/El0lDk= X-Received: by 2002:aca:ea41:: with SMTP id i62mr108988oih.144.1565212528591; Wed, 07 Aug 2019 14:15:28 -0700 (PDT) MIME-Version: 1.0 References: <4195597.6UoUMpgHb9@l5580> <6247286.Dd9LSJjpfE@l5580> In-Reply-To: <6247286.Dd9LSJjpfE@l5580> From: Seth Blank Date: Wed, 7 Aug 2019 14:15:12 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c3df23058f8d7009" Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 07 Aug 2019 21:15:32 -0000 --000000000000c3df23058f8d7009 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 2, 2019 at 3:31 PM Scott Kitterman wrote: > Is silence concurrence? Comments inline. Please let me know how to > proceed > on updating the draft. I'd appreciate anyone else's feedback too. > Addressing only this point, yes, I concur with all of Murray's comments and requests. --000000000000c3df23058f8d7009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 2, 2019 at 3:31 PM Scott Kitt= erman <sklist@kitterman.com&= gt; wrote:
Is silence concurrence?=C2=A0 Comments inline.=C2=A0 = Please let me know how to proceed
on updating the draft.=C2=A0 =C2=A0I'd appreciate anyone else's fee= dback too.

Addressing only this point, = yes, I concur with all of Murray's comments and requests.=C2=A0
--000000000000c3df23058f8d7009-- From nobody Thu Aug 8 02: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 664EE12011C for ; Thu, 8 Aug 2019 02:48: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 Ve1Me6RSQRgJ for ; Thu, 8 Aug 2019 02:48:43 -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 02B7C120044 for ; Thu, 8 Aug 2019 02:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565257720; bh=v1vOxvG8yCuysxrrSx2B0O6x6OrbHQNVtjGUM1D7fhE=; l=1208; h=To:Cc:References:From:Date:In-Reply-To; b=AOmw8SmI6zcei2bocMXTGXAoAs9dCYixELATPrt51IxzTZslV1iH4ZXzZddWBI5B8 5MhlypBfoiZ4tkRXsTSuUYwQEVEWNuOVIBVSuQmyOHBEoVKdfuJxfhiA1rALHynLRW i53V1/0H+lCFvO96bTGjYiDTn4OctYH6oXmTkTbjINrp7P69kWcNkoDU5Rtt1 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.101] ([5.170.69.76]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005D4BEFF8.0000610C; Thu, 08 Aug 2019 11:48:40 +0200 To: "Murray S. Kucherawy" , Matthias Leisi Cc: IETF DMARC WG References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Thu, 8 Aug 2019 11:48:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 09:48:44 -0000 On Wed 07/Aug/2019 17:14:22 +0200 Murray S. Kucherawy wrote: > On Sat, Aug 3, 2019 at 8:28 AM Alessandro Vesely wrote: >> >> IOW, dnswl=pass means the sender was whitelisted. > > > If that's the case, why do downstream agents need "policy.ip" at all? To be whitelisted just means that the sender is a legitimate SMTP server, AFAICS. I add Matthias to the recipients list as he can be much more precise on such criteria, at least for the whitelist he runs. policy.ip carries more details. In my use case, "HEURISTIC" viruses have a significant probability of being false positive. A downstream filter extracts the trustworthiness from the policy.ip and makes a decision based on that value. Note that this filter runs after the AV filter, after the end of DATA, while dnswl=pass can be used at HELO to mitigate SPF forwarding issues. Some ISPs, albeit whitelisted, either have policies so sloppy as to tolerate infected customers, or don't spend enough energy to sanitize them anyway. The trustworthiness somehow reflects that quality. Dnswl.org also reports the category, another octet of policy.ip. Best Ale -- https://tools.ietf.org/html/draft-vesely-authmethod-dnswl From nobody Thu Aug 8 03:34: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 4AA41120133 for ; Thu, 8 Aug 2019 03:34:46 -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 5ioMHC3I2nuq for ; Thu, 8 Aug 2019 03:34: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 B8B2512011C for ; Thu, 8 Aug 2019 03:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565260481; bh=q2khlVfUeC9vkuBlXF9yc5ayHE5GZgmUEjl57qPoZjU=; l=8826; h=To:References:From:Date:In-Reply-To; b=CgvMQf+atlUQBcsKD0NJtGatIfoOxvNUC2paHLtXMTEIPs+QKsm+LMJ2zTmTqzKCA h7FyIV9S0RY1D85fQIfG/3zCJMD0e3XxdEcd1krN19viz+StRPlN2aob4qO1kyn0cb Mkl5SSkcDji/fCyq+CKwKJwlV0v+xVjVhcJj3/zQc2LS1nwKimepYCh77GMSJ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.101] ([5.170.69.76]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.000000005D4BFAC1.00006697; Thu, 08 Aug 2019 12:34:41 +0200 To: dmarc@ietf.org References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> <018e01d54d35$2a603050$7f2090f0$@leemankuiper.nl> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Thu, 8 Aug 2019 12:34:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <018e01d54d35$2a603050$7f2090f0$@leemankuiper.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 08 Aug 2019 10:34:47 -0000 No, wait a minute, what are we talking about? I've re-browsed this thread, and various passages seem to be talking about failure reports. The Network Error Logging is also similar to failure reports inasmuch as they talk of logging each instance of a class of events, or a percentage thereof. *Aggregate* reports arrive once a day, and millions of successful messages from a handful of IP addresses result in a handful of records, reported within a single message, along with any failures. The bandwidth difference is negligible. Multiply that by the number of mailbox providers, what is it? I never experimented frequencies higher than once every 24 hours, neither for the ri= I set, nor for honoring requests —I run the process once a day. Anyway, I reckon that sending more often increases the total amount of data sent, hence the bandwidth. If it is problematic to receive all those reports, the protocol should specify a different sending strategy. IMHO, that's not the case. Best Ale -- On Wed 07/Aug/2019 17:31:21 +0200 Freddie Leeman wrote: > I agree that messages with both DKIM and SPF pass results can be useful when it comes to validating that everything is (still) in working order. But I come across domains with very high email volumes. So daily reports contain thousands of records that are consuming bandwidth, storage and processing power and in most cases aren't looked at (except for a count maybe). What could be the best of both worlds would be to add a ‘success_fraction’ tag that allows a domain owner to specify a fraction between 0 and 1 (1 being the default) just like https://www.w3.org/TR/network-error-logging/#the-success_fraction-member. I would still receive success reports but a 0.0001 fraction for instance. That will still allow me to detect fluctuation and changes while limiting the amount of records drastically. This would even allow domain owners to block success reports completely by setting a fraction of 0. > > Your thoughts? > > Van: Dotzero [mailto:dotzero@gmail.com] > Verzonden: donderdag 1 augustus 2019 00:22 > Aan: Дилян Палаузов > CC: Freddie Leeman ; IETF DMARC WG > Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' > > Having both passes and failures is incredibly useful. The percentage of failures is very useful. Any set of mail streams will always have some failures. Once you know what the baseline rate for a (sub)domain is, simply seeing changes in that rate will help you identify problems.. An increase in the failure rate is generally either 1) someone trying to abuse your domain name; or 2) something has gone wrong with DKIM signing or someone associated with the domain organization has started sending mail from somewhere without appropriate SPF or DKIM. > > Michael Hammer > > On Wed, Jul 31, 2019 at 5:24 PM Дилян Палаузов wrote: > Hello Fredie, > > DMARC limits the amount of servers that can generate emails for a particular domain. The aggregate reports show to which extend DMARC does work correctly and when it fails for a domain. The aggregate reports to not tell you how to fix your DKIM implementation, so that sender and receiver agree on the DKIM signature. The per message failure reports tell you which messages were not signed correctly, so that you can check the DKIM implementation. > > I thought some hours ago it could be useful to reduce the amount of reports, by not sending a report when things are 100% correct, but now I am not so sure. > > The aggregate reports contain information, if something is not working correctly, but they also prove, if everything is running correctly. If there is an option to reduce the reports to contain only information about failures, you don’t have a prove, that everything is working correctly. Let’s say if you write a message to site S and don’t get an aggregate report back, this can mean, that DMARC passed, but it can also mean, that S does not evaluate DMARC or that DMARC failed and S does not send aggregate reports. Is the lack of success-reports a prove of correctness or not? I am inclined. > > What do you want to do with the information about failures from the DMARC aggregate reports? > > Regards > Дилян > > On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote: >> Hi Дилян, >> >> Thanks for your input and feedback. Maybe a single tag, that allows the domain owner to avoid receiving aggregate reports for messages that align, would be enough? I personally have little experience with mailing lists which, I understand, can be a real pain when it comes to SPF/DKIM. So would a tag that instructs the receiving party to only send an aggregate report whenever the DMARC policies is applied be a better option? >> >> Kind regards, >> Freddie >> >> Van: Дилян Палаузов [mailto:dilyan.palauzov@aegee.org] >> Verzonden: woensdag 31 juli 2019 17:29 >> Aan: dmarc@ietf.org >> Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' >> >> Hello Freddie, >> >> if a message has 5 DKIM-Signatures, some of them fail DKIM validation and some of them do not align, irrespective of validation status, you want to receive a report for the failed DKIM signatures. The proposed option d is in the DKIM domain. DMARC without alignment is DKIM or SPF. To get a report for failed DKIM signature you put in the DKIM-Signature header r=y. After the mail passes over a mailing list, the signature is invalidated and you get a useless report. Your intension is to limit the amount of useless reports, but this particular option goes in the opposite direction. >> >> If you remove the SPF records and ensure that each leaving message is signed, you do not need the ao=1 option, as each report on failure will be about DKIM. >> >> With ao=s whenever a mail is sent to an alias and redirected to another server, you will get a useless report. I am not exactly sure, but I think SPF contained some reporting mechanisms, so this option might duplicate them. >> >> Perhaps you want to propose a mechanism, that hides the successful deliveries (useless report) and only reports problematic cases? >> >> Regards >> Дилян >> >> >> On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman wrote: >>> Would it be useful to add an ‘ao’ tag name for aggregate reporting options? Something like: >>> >>> ao: Aggregate reporting options (plain-text; OPTIONAL; default is "0"). >>> Provides requested options for generation of aggregate reports. This tag's content MUST be ignored if a "rua" tag is not specified. The value of this tag is a colon-separated list of characters that indicate aggregate reporting options as follows: >>> >>> 0: Generate a DMARC aggregate report for every message, regardless of its alignment. >>> 1: Generate a DMARC aggregate report if any underlying authentication mechanism produced something other than an aligned "pass" result. >>> d: Generate a DMARC aggregate report if the message had a signature that failed evaluation, regardless of its alignment. >>> s: Generate a DMARC aggregate report if the message failed SPF evaluation, regardless of its alignment. >>> >>> This would allow domain owners to save on tons of reports to be handled and processing that are useless in most scenarios. For instance, when I’ve deployed my SPF/DKIM/DMARC policy and I’m pleased with my policie’s results, I would still want to use the reporting to detect and fix changes in my email environment. If a million mails a day are nicely processed with DKIM and SPF aligned, I do not need those entries in my aggregate reports. I’m only interested in the reports where either DKIM or SPF fails. In most scenario’s this will cut data transfer and report processing with more than 99 percent. Whenever there is a bump in the number of reports received, I can detect that something is wrong and I might need to add a host to my SPF policy or need to fix my DKIM signing. >>> >>> I was amazed that these options weren’t in the current RFC, as these do exist for failure reports. Am I missing something? Is there a reason why this would be a bad idea? >>> >>> Kind regards, >>> Freddie >> >> _______________________________________________ >> 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 > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Thu Aug 8 04:11: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 0CC8312025F for ; Thu, 8 Aug 2019 04:11:38 -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 yiCtyxhe2mHE for ; Thu, 8 Aug 2019 04:11:36 -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 AABF412024D for ; Thu, 8 Aug 2019 04:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565262694; bh=GBoeGM7jKSDvIBVNYpeHlp7hyyI2zKWC/KHFsdJWp7s=; l=760; h=To:References:From:Date:In-Reply-To; b=CVahvGhwgCaogSexJDNYLT411qCNB+xsPd/7gZfGGj1lTwPFsrQG0vCNclUotBnTc KiWzWQU4nqnU6dXNxqigNqHbv0W2yjlPCycoQUAVh/xZJdrkm6P1Dan6SREagLHNn6 EcS5ZC6+HoNBZTe9n4ZmI5ZNBJE4LgoZHek8H9LufUbRp4+K4jdlGSaR+z+of Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.101] ([5.170.69.76]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.000000005D4C0366.00006C59; Thu, 08 Aug 2019 13:11:33 +0200 To: dmarc@ietf.org References: <016301d54d26$88020f30$98062d90$@leemankuiper.nl> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Thu, 8 Aug 2019 13:11:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Missing report elements and dmarc.org information based on deprecated drafs 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, 08 Aug 2019 11:11:38 -0000 On Wed 07/Aug/2019 17:54:53 +0200 Murray S. Kucherawy wrote: > On Wed, Aug 7, 2019 at 6:46 AM Freddie Leeman 40leemankuiper.nl@dmarc.ietf.org> wrote: > >> I've been digging through the DMARC pre-IETF drafts and IETF drafts and >> came to the following conclusion: >> > > Seems to me the working group has a choice to make here, somewhere between > "reinforce the XML specification as published" and "take the consensus of > what's implemented and publish that as the revised standard". Either way, > this should certainly be a work item for standards track DMARC. I vote "reinforce the XML specification as published". I assume that is going to mean the next, standard track publication, not any obsolete one. Best Ale -- From nobody Thu Aug 8 05: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 63EB9120046 for ; Thu, 8 Aug 2019 05:30:58 -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 (2048-bit key) header.d=leemankuiper.nl 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 GZxXX7F7sxjY for ; Thu, 8 Aug 2019 05:30:54 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 A351812001A for ; Thu, 8 Aug 2019 05:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6SKRuRZKFkvNfZ4vH4NHlf2Y9BvVn2kfaEiGDkJC5sQ=; b=KqJIgBw7KJ0HoL1jSYfYMv+NM0 829NPb+P7FQ6FMqdJ8rjXZ5DiUSxkR+W26okSj3JP6IQ0USGnXGUS9ynYdsC3XjrlVsPIQSXsB0H7 JVBG8pVxPZh92BpG4PUJRIv7G2+8zP4UMGqbmWEL/kjhBo6d2NQWb8iQMqoWyaztyUUGhMPoD8Nr1 X3R1buZ/icFhW/ffD7R8Mmc6eitF2oR0DvuB7xkNWPRoxDhkasjXMvqzCrlxSzHTmI3kEHSnJC5Yk 5rkSkQVo+F/iGbPCWhzdOTmwW8lxLvLfk+9cNlkCC4uhxanZbhaMDYZTf4hI38wAAK552gjLSV3wa 9ve8JiMQ==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hvhZE-0002Xb-L4; Thu, 08 Aug 2019 14:30:52 +0200 From: "Freddie Leeman" To: "'Alessandro Vesely'" , References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> <018e01d54d35$2a603050$7f2090f0$@leemankuiper.nl> In-Reply-To: Date: Thu, 8 Aug 2019 14:30:51 +0200 Message-ID: <121801d54de5$1dfc4820$59f4d860$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJIu0T9j5Gm574QYreI9/dffuh59gHbOLplAhC8NysA7c3suQMM09lzAqL6vhAA/DW9h6WuI4vw Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: freeman Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 08 Aug 2019 12:30:59 -0000 Wait, you are right. I was talking about aggregate reports. But since = the reports contains a single record per source IP this shouldn't be = much data unless the domain has a huge range of (SPF allowed) sources. = In case of a large scale abuse the messages would fail both DKIM and SPF = and you want those reports, even if there are thousands. Thank you for = clearing this up. I think we can put this threat to rest. -----Oorspronkelijk bericht----- Van: Alessandro Vesely [mailto:vesely@tana.it]=20 Verzonden: donderdag 8 augustus 2019 12:35 Aan: dmarc@ietf.org Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' No, wait a minute, what are we talking about? I've re-browsed this thread, and various passages seem to be talking = about failure reports. The Network Error Logging is also similar to = failure reports inasmuch as they talk of logging each instance of a = class of events, or a percentage thereof. *Aggregate* reports arrive = once a day, and millions of successful messages from a handful of IP = addresses result in a handful of records, reported within a single = message, along with any failures. The bandwidth difference is = negligible. Multiply that by the number of mailbox providers, what is = it? I never experimented frequencies higher than once every 24 hours, = neither for the ri=3D I set, nor for honoring requests =E2=80=94I run = the process once a day. Anyway, I reckon that sending more often = increases the total amount of data sent, hence the bandwidth. If it is = problematic to receive all those reports, the protocol should specify a = different sending strategy. IMHO, that's not the case. Best Ale --=20 On Wed 07/Aug/2019 17:31:21 +0200 Freddie Leeman wrote: > I agree that messages with both DKIM and SPF pass results can be = useful when it comes to validating that everything is (still) in working = order. But I come across domains with very high email volumes. So daily = reports contain thousands of records that are consuming bandwidth, = storage and processing power and in most cases aren't looked at (except = for a count maybe). What could be the best of both worlds would be to = add a =E2=80=98success_fraction=E2=80=99 tag that allows a domain owner = to specify a fraction between 0 and 1 (1 being the default) just like = https://www.w3.org/TR/network-error-logging/#the-success_fraction-member.= I would still receive success reports but a 0.0001 fraction for = instance. That will still allow me to detect fluctuation and changes = while limiting the amount of records drastically. This would even allow = domain owners to block success reports completely by setting a fraction = of 0. >=20 > Your thoughts? > =20 > Van: Dotzero [mailto:dotzero@gmail.com] > Verzonden: donderdag 1 augustus 2019 00:22 > Aan: =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 = > CC: Freddie Leeman ; IETF DMARC WG=20 > > Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' >=20 > Having both passes and failures is incredibly useful. The percentage = of failures is very useful. Any set of mail streams will always have = some failures. Once you know what the baseline rate for a (sub)domain = is, simply seeing changes in that rate will help you identify problems.. = An increase in the failure rate is generally either 1) someone trying to = abuse your domain name; or 2) something has gone wrong with DKIM signing = or someone associated with the domain organization has started sending = mail from somewhere without appropriate SPF or DKIM. >=20 > Michael Hammer >=20 > On Wed, Jul 31, 2019 at 5:24 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 Fredie, >=20 > DMARC limits the amount of servers that can generate emails for a = particular domain. The aggregate reports show to which extend DMARC = does work correctly and when it fails for a domain. The aggregate = reports to not tell you how to fix your DKIM implementation, so that = sender and receiver agree on the DKIM signature. The per message = failure reports tell you which messages were not signed correctly, so = that you can check the DKIM implementation. >=20 > I thought some hours ago it could be useful to reduce the amount of = reports, by not sending a report when things are 100% correct, but now I = am not so sure. >=20 > The aggregate reports contain information, if something is not working = correctly, but they also prove, if everything is running correctly. If = there is an option to reduce the reports to contain only information = about failures, you don=E2=80=99t have a prove, that everything is = working correctly. Let=E2=80=99s say if you write a message to site S = and don=E2=80=99t get an aggregate report back, this can mean, that = DMARC passed, but it can also mean, that S does not evaluate DMARC or = that DMARC failed and S does not send aggregate reports. Is the lack of = success-reports a prove of correctness or not? I am inclined. >=20 > What do you want to do with the information about failures from the = DMARC aggregate reports? >=20 > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD >=20 > On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote: >> Hi =D0=94=D0=B8=D0=BB=D1=8F=D0=BD, >> =20 >> Thanks for your input and feedback. Maybe a single tag, that allows = the domain owner to avoid receiving aggregate reports for messages that = align, would be enough? I personally have little experience with mailing = lists which, I understand, can be a real pain when it comes to SPF/DKIM. = So would a tag that instructs the receiving party to only send an = aggregate report whenever the DMARC policies is applied be a better = option? >> =20 >> Kind regards, >> Freddie >> =20 >> Van: =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 = [mailto:dilyan.palauzov@aegee.org] >> Verzonden: woensdag 31 juli 2019 17:29 >> Aan: dmarc@ietf.org >> Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' >> =20 >> Hello Freddie, >> >> if a message has 5 DKIM-Signatures, some of them fail DKIM validation = and some of them do not align, irrespective of validation status, you = want to receive a report for the failed DKIM signatures. The proposed = option d is in the DKIM domain. DMARC without alignment is DKIM or SPF. = To get a report for failed DKIM signature you put in the DKIM-Signature = header r=3Dy. After the mail passes over a mailing list, the signature = is invalidated and you get a useless report. Your intension is to limit = the amount of useless reports, but this particular option goes in the = opposite direction. >> >> If you remove the SPF records and ensure that each leaving message is = signed, you do not need the ao=3D1 option, as each report on failure = will be about DKIM. >> >> With ao=3Ds whenever a mail is sent to an alias and redirected to = another server, you will get a useless report. I am not exactly sure, = but I think SPF contained some reporting mechanisms, so this option = might duplicate them. >> >> Perhaps you want to propose a mechanism, that hides the successful = deliveries (useless report) and only reports problematic cases? >> >> Regards >> =D0=94=D0=B8=D0=BB=D1=8F=D0=BD >> >> >> On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman = wrote: >>> Would it be useful to add an =E2=80=98ao=E2=80=99 tag name for = aggregate reporting options? Something like: >>> =20 >>> ao: Aggregate reporting options (plain-text; OPTIONAL; = default is "0"). >>> Provides requested options for generation of aggregate reports. This = tag's content MUST be ignored if a "rua" tag is not specified. The value = of this tag is a colon-separated list of characters that indicate = aggregate reporting options as follows: >>> =20 >>> 0: Generate a DMARC aggregate report for every message, regardless = of its alignment. >>> 1: Generate a DMARC aggregate report if any underlying = authentication mechanism produced something other than an aligned "pass" = result. >>> d: Generate a DMARC aggregate report if the message had a signature = that failed evaluation, regardless of its alignment. >>> s: Generate a DMARC aggregate report if the message failed SPF = evaluation, regardless of its alignment. >>> =20 >>> This would allow domain owners to save on tons of reports to be = handled and processing that are useless in most scenarios. For instance, = when I=E2=80=99ve deployed my SPF/DKIM/DMARC policy and I=E2=80=99m = pleased with my policie=E2=80=99s results, I would still want to use the = reporting to detect and fix changes in my email environment. If a = million mails a day are nicely processed with DKIM and SPF aligned, I do = not need those entries in my aggregate reports. I=E2=80=99m only = interested in the reports where either DKIM or SPF fails. In most = scenario=E2=80=99s this will cut data transfer and report processing = with more than 99 percent. Whenever there is a bump in the number of = reports received, I can detect that something is wrong and I might need = to add a host to my SPF policy or need to fix my DKIM signing. >>> =20 >>> I was amazed that these options weren=E2=80=99t in the current RFC, = as these do exist for failure reports. Am I missing something? Is there = a reason why this would be a bad idea? >>> =20 >>> Kind regards, >>> Freddie >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Thu Aug 8 05:53: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 1EEEF120221 for ; Thu, 8 Aug 2019 05:53: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, 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=leemankuiper.nl 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 DFN2QHKqq4YN for ; Thu, 8 Aug 2019 05:53:01 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 355681201E3 for ; Thu, 8 Aug 2019 05:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4w7W0iBHUAaRw/0GheZa65UoCJ3g4vBkkv5nTjMQ1VY=; b=B94COakEI0j2Q+MYhJvTvu0gbZ CHoXJCpRsV+rkUX8Wl9LflWOEbzmeVfipKCAbI7iok5/hyGK6ypP1AFYmcgBxkowXz/dGq8a1jlyF UL6zCkJNou3Z9ASBnNMJ1a7sMLNuLoM60OiIn+s0cU9peObzHTaa1BxcBwkdCBVwFOymeSrrrjZ2/ SZdYIwvLNTkBwE8iq6vC/YYDYWFwfKEgkq3Xct60GcEg0ofg8ABdskhyvQpWNi7gK4RRjXhkDZPNr AskS3C6xDbwvrYeNlWHjymq5bVIgwvbVKqFM5ok+Z4V51F34jVR/AtqrnrffELKAuXTDNobQqjJpm ZnsDeb8g==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hvhud-0002vo-8s for dmarc@ietf.org; Thu, 08 Aug 2019 14:52:59 +0200 From: "Freddie Leeman" To: References: <00ba01d54ca3$69ffce10$3dff6a30$@leemankuiper.nl> In-Reply-To: <00ba01d54ca3$69ffce10$3dff6a30$@leemankuiper.nl> Date: Thu, 8 Aug 2019 14:52:58 +0200 Message-ID: <134ba01d54de8$34b61fc0$9e225f40$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIfy2mjUVHj61yfYSQzm4Ru5o3Q/qZcNw5A Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: freeman Archived-At: Subject: Re: [dmarc-ietf] Should 'undeliverable mail' be included in DMARC rua 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, 08 Aug 2019 12:53:03 -0000 So how should 'null reverse-path'-messages be processed (in the future)? = I see three options: =20 - Element's minOccurs gets changed to 0 and =E2=80=98null = reverse-path=E2=80=99 messages are added without the 'envelope_from' = element - Element's minOccurs stays 1 and =E2=80=98null reverse-path=E2=80=99 = messages get an empty 'envelope_from' value - =E2=80=98null reverse-path=E2=80=99 messages are excluded from DMARC = reports Do 'null reverse-path' messages add any substantial value to DMARC = reports? Pros/Cons? Your thoughts? -- Freddie Leeman From nobody Thu Aug 8 09:50:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00B912024B for ; Thu, 8 Aug 2019 09:50:43 -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 73mw0DNPlxTF for ; Thu, 8 Aug 2019 09:50:42 -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 A7605120290 for ; Thu, 8 Aug 2019 09:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565283033; bh=zKGSShzmQWjdVJD0cImIH4o50B5abdidbTmxpv9Ny84=; l=713; h=To:References:From:Date:In-Reply-To; b=ACZld0MZgOFY37UPZN64AMwFJIt3jwzMNgW931nW07NGIXLeJIV6pQAXp932+kEf+ FjQVvDUjUnDtnfZeS163I0F4QcI0J/d1rfUCPYMhxxgwk70lAJXXKkujKWIIi+7L7B 4vrXP4z54it0rwDVFOVkvL7ynwbMoCYLSiDjwMFh53bvZuSFaAfhXBWctPUer Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.101] ([5.170.68.241]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC064.000000005D4C52D9.00001D36; Thu, 08 Aug 2019 18:50:33 +0200 To: dmarc@ietf.org References: <00ba01d54ca3$69ffce10$3dff6a30$@leemankuiper.nl> <134ba01d54de8$34b61fc0$9e225f40$@leemankuiper.nl> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Thu, 8 Aug 2019 18:50:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <134ba01d54de8$34b61fc0$9e225f40$@leemankuiper.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Should 'undeliverable mail' be included in DMARC rua 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, 08 Aug 2019 16:50:55 -0000 On Thu 08/Aug/2019 14:52:58 +0200 Freddie Leeman wrote: > So how should 'null reverse-path'-messages be processed (in the future)? I see three options: > > - Element's minOccurs gets changed to 0 and ‘null reverse-path’ messages are added without the 'envelope_from' element > - Element's minOccurs stays 1 and ‘null reverse-path’ messages get an empty 'envelope_from' value This option is easy to grasp, as it parallels SMTP's mail from:<> > - ‘null reverse-path’ messages are excluded from DMARC reports > > Do 'null reverse-path' messages add any substantial value to DMARC reports? Not less nor more than the ones having a possibly spoofed reverse path. jm2c Ale -- From nobody Thu Aug 8 19:04: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 06BD912002F for ; Thu, 8 Aug 2019 19:04:30 -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=Zt0SGPx4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rTL6V9ea 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 qFOy7P9RJbOK for ; Thu, 8 Aug 2019 19:04:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04B412008A for ; Thu, 8 Aug 2019 19:04:27 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EF05E22091; Thu, 8 Aug 2019 22:04:26 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Thu, 08 Aug 2019 22:04:26 -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 :cc:subject:content-type; s=fm1; bh=b8tTJ4HLlimFa4ujXDoWafxCsn7Z 1Qmm2R2pSQ/eNXA=; b=Zt0SGPx4AIqmGtQU8+wdd/tY6Za1DF2qE1lmtrRE8Ajp m2QM4ka4TttujHP/qDsgtINT6FmCtiLndNVYvKNTqk/PzWmdjhUaTe2RCVFqphoi EoSdeWAKHR2bUp+wzBwo2Akk2e0uRgens0YDDa/zHMRhBDj4jLuqtiycLqDyij0k +CssUUr42e3q89iSWVFhaYtYlXmT9LIZlFrX2acUb+YIhATqQI45Scd/TWE+uqE8 zIY6zYd51+Ag09fnq17kCRKbHG9JXbY9fzbt+fc/MzOBz1Ga5qBcB/irEsdZCi6Y cseGS6HCcw7hchA9q4BYNmTRhlb4HaWaZXZx4nqZIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=b8tTJ4 HLlimFa4ujXDoWafxCsn7Z1Qmm2R2pSQ/eNXA=; b=rTL6V9eaNd3CqgQ0DppxAh 5CyPCXjqO8w+eXxGKvb2t9oXpjqSX3fXQRFaMVqjNWx8E/pVmstFf79+/X9EKtgx jriuq28t0RTiJ5MAGhkyZaS1MY6jn4iK7Xf2DjpYy93mnaXhtsBWnIToGOsiXDS5 w2RzEmoVPLhbcfRZZYpsZWlTclEm6iI27WhjsBrgYOyHh77XHIB95wEttwAw5urk ws8EImbxVca/2N8BeVY1nKmhKIMbrAcLqFyKJh2KaFl2JOYJCs8T3ljzIT0QX6m6 +JdQqthi85rTWNDf4FbivCJZWVrBqYYY5BcGi/YwVw6bJ3LCkkmAY0gFG/F8JxwA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduiedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuthgr nhcumfgrlhhishgthhdfuceoshhtrghnsehglhihphhhvghinhdrmhgrihhlfhhorhgtvg drnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhn rdhmrghilhhfohhrtggvrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BEE951400EE; Thu, 8 Aug 2019 22:04:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> Date: Thu, 08 Aug 2019 22:04:25 -0400 From: "Stan Kalisch" To: "Murray S. Kucherawy" , "Alessandro Vesely" Cc: "IETF DMARC WG" Content-Type: multipart/alternative; boundary=3bdef50581294b7b922ba417f524b809 Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?Do_is_need_a_new_ptype=3F_Was_Re=3A_New_a?= =?utf-8?q?uthentication_method=2C_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: Fri, 09 Aug 2019 02:04:30 -0000 --3bdef50581294b7b922ba417f524b809 Content-Type: text/plain On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote: > On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: >> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, >> does not contain the term "policy". > > Wow. I'm amazed I got away with that. > > But it is clear from the things in the registry that that's how you do it. > >> My recollection is that reporting the >> client IP is immaterial, as for SPF. The term policy.iprev is certainly >> misleading, since the value is not related to a locally-defined policy, and is >> not a reversed ip. To stick with A-R semantics, it should have been named >> tcp.ip, remote.ip or some such. If a property warrants deprecation, it's >> policy.iprev. > > The choice of "policy" for "iprev" is rooted in history, because the earlier versions of the document (as you well know) demanded that the things being reported had something to do with the message itself. "iprev" was an exception the community chose to allow. It pre-dated RFC5782 which introduced DNSxLs formally. > > For guidance here, I would rely on anecdotes of implementation. Has anyone implemented something that attaches "iprev" results? IIRC, Fastmail's Authentication Milter does. But I also have some vague recollection that they stopped using policy.iprev, specifically. Now looking at headers from my Fastmail customer account, it appears to me that this is indeed what they did, although I would have to recheck the actual distribution they share with everyone else to be sure. I'm sure someone at Fastmail can comment on what actually precipitated the move. Stan > >> Now for dnswl. Knowing which zone was queried is substantial in order to >> interpret policy.ip, because there is no standard format. Yet, an >> implementation could just throw a DNS query to a given local IP, instead of a >> FQDN to the default DNS server. In that case, one would have, for example: >> >> dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2 >> >> In that case one can hardly tell which is which. A meaningful ptype helps. > > Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"? I would expect it to have that knowledge, not downstream things. Again, I don't know what the value of "dnswl=pass" is if the thing attaching it doesn't even know how to interpret the result it got. --3bdef50581294b7b922ba417f524b809 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy = wrote:
On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely <vesely@tana.it> wrote:
Let me note = that Section 3 of rfc8601, /The "iprev" Authentication Method/,
does not contain the term "policy".

Wow.  I'm amazed I got awa= y with that.

But it is clear from the thing= s in the registry that that's how you do it.

My recollection is that reporting the
=
client IP is immaterial, as for = SPF.  The term policy.iprev is certainly
misleading, since the value is not related to a locally= -defined policy, and is
not a= reversed ip.  To stick with A-R semantics, it should have been nam= ed
tcp.ip, remote.ip or some = such.  If a property warrants deprecation, it's
policy.iprev.

The choice of "policy" for "iprev" is rooted in history, because= the earlier versions of the document (as you well know) demanded that t= he things being reported had something to do with the message itself.&nb= sp; "iprev" was an exception the community chose to allow.  It pre-= dated RFC5782 which introduced DNSxLs formally.

=
For guidance here, I would rely on anecdotes of implementation.&nbs= p; Has anyone implemented something that attaches "iprev" results?

IIRC, Fastmail's Authentication Milte= r does.  But I also have some vague recollection that they stopped = using policy.iprev, specifically.

Now looking at headers = from my Fastmail customer account, it appears to me that this is indeed = what they did, although I would have to recheck the actual distribution = they share with everyone else to be sure.  I'm sure someone at Fast= mail can comment on what actually precipitated the move.

=
Stan


Now for dnswl.  Knowing which zone was queried is= substantial in order to
inte= rpret policy.ip, because there is no standard format.  Yet, an
<= /div>
implementation could just throw a= DNS query to a given local IP, instead of a
FQDN to the default DNS server.  In that case, one = would have, for example:

=
   dnswl=3Dpass policy= .ip=3D127.0.9.2 policy.zone=3D127.0.0.2

In that case one = can hardly tell which is which.  A meaningful ptype helps.

Why would= the thing attaching "dnswl=3Dpass" not also interpret "policy.ip"? = ; I would expect it to have that knowledge, not downstream things. = Again, I don't know what the value of "dnswl=3Dpass" is if the thing at= taching it doesn't even know how to interpret the result it got.
--3bdef50581294b7b922ba417f524b809-- From nobody Thu Aug 8 21:29: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 C21621200CE for ; Thu, 8 Aug 2019 21:29:42 -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 (2048-bit key) header.d=marcbradshaw.net header.b=k6FBUY5s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EAdQpHDX 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 3Ikk_sGTfl8t for ; Thu, 8 Aug 2019 21:29:40 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B071200A3 for ; Thu, 8 Aug 2019 21:29:40 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A98C921F2E for ; Fri, 9 Aug 2019 00:29:39 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute2.internal (MEProxy); Fri, 09 Aug 2019 00:29:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=7ZGXUfx 1amW0zt4lZFNDePef2syKmvSKispS8zR5OyE=; b=k6FBUY5spsZ3osb9h/S5vu3 YD/9iDZne2bE6H577Kv7zbiX4fFOlhqBX4yHRU+GdIJXXaZGro27cD0lg7sPo93N d88cW1U0NMmTjKugNLoyeFUmRlwDTiMtbdGI+wblqVckumaf8/LlwyYZuaRD9dzu jqYyjmJXesBH0WbccBMSy/9mxhJskqf/jGduQDgJ4T4LNzAdwTi4vlDIfOA7A267 arEgDHfTorDAu5VtZdJpE9GpPFkz9V24c0SXTG20ZqU5DaznzbwUZJOxOYyKpS/O xR256kiw9+T58Co91qUdOKfljhXTk+tOw6vPRO5j1iOGjzKTZNnHeIFMifz4MZw= = 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=7ZGXUf x1amW0zt4lZFNDePef2syKmvSKispS8zR5OyE=; b=EAdQpHDXUBzKii7LrgxFV1 2VAXfzD6BpXGnKN1hm2NO4xU6ptTpGcYK7nEuRVTYE7Day2NsCoi/hzpKmq+6QIF Oq6yKHCNNUiTWHIsxKO5acqOL1rVZ4ZIwEqc2ODryxIX35+wgpIEXYlw+x3uwRhw /wMS0wgX4I0jM+w3aZnlyLvAV2YDXqPn6/oHjSaI2IgEi/neORJdg0SDcbmSnJ+f P7m1BE8+mhJ+CBIBq0tUy16/fStZl+j70QWGKuZJRd+f5k4r3Ztk1rX9+oNl+BTL iemrqDnyhIL3ow7LT7Hlo/OJRTxDtdianyFoXGj9KFVUBVL8IWBuTzPOtmHBuRQA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduiedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdforghr tgcuuehrrggushhhrgiffdcuoehmrghrtgesmhgrrhgtsghrrggushhhrgifrdhnvghtqe enucffohhmrghinhepthifihhtthgvrhdrtghomhdpmhgrrhgtsghrrggushhhrgifrdhn vghtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrtgesmhgrrhgtsghrrggushhhrg ifrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 250994C000A4; Fri, 9 Aug 2019 00:29:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: <03c58290-1b4b-4dac-a7f3-d66a4be4d3a0@www.fastmail.com> In-Reply-To: References: <4783309.BXR8ZdE9c3@l5580> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> Date: Fri, 09 Aug 2019 14:28:50 +1000 From: "Marc Bradshaw" To: "DMARC IETF" Content-Type: multipart/alternative; boundary=3a63167ba2794788bdb5f5eedcdd46c7 Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?Do_is_need_a_new_ptype=3F_Was_Re=3A_New_a?= =?utf-8?q?uthentication_method=2C_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: Fri, 09 Aug 2019 04:29:43 -0000 --3a63167ba2794788bdb5f5eedcdd46c7 Content-Type: text/plain On Fri, 9 Aug 2019, at 12:04 PM, Stan Kalisch wrote: > On Fri, Aug 2, 2019, at 3:58 PM, Murray S. Kucherawy wrote: >> On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: >>> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, >>> does not contain the term "policy". >> >> Wow. I'm amazed I got away with that. >> >> But it is clear from the things in the registry that that's how you do it. >> >>> My recollection is that reporting the >>> client IP is immaterial, as for SPF. The term policy.iprev is certainly >>> misleading, since the value is not related to a locally-defined policy, and is >>> not a reversed ip. To stick with A-R semantics, it should have been named >>> tcp.ip, remote.ip or some such. If a property warrants deprecation, it's >>> policy.iprev. >> >> The choice of "policy" for "iprev" is rooted in history, because the earlier versions of the document (as you well know) demanded that the things being reported had something to do with the message itself. "iprev" was an exception the community chose to allow. It pre-dated RFC5782 which introduced DNSxLs formally. >> >> For guidance here, I would rely on anecdotes of implementation. Has anyone implemented something that attaches "iprev" results? > > IIRC, Fastmail's Authentication Milter does. But I also have some vague recollection that they stopped using policy.iprev, specifically. > > Now looking at headers from my Fastmail customer account, it appears to me that this is indeed what they did, although I would have to recheck the actual distribution they share with everyone else to be sure. I'm sure someone at Fastmail can comment on what actually precipitated the move. We (Fastmail) do attach IPRev results. We used policy.iprev for the remote IP up until October 2018, although it may have been slightly later when the change made it through to production. I recall the change being made as part of a larger set of changes which came out of an ARC interop working session. Current code uses smtp.remote-ip for a few reasons, mostly as it is more correct to attach this to the IP to the smtp type, it is also more in line with what some other providers are doing. For context, we are using this when processing messages with a trusted ARC set. -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --3a63167ba2794788bdb5f5eedcdd46c7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, 9 = Aug 2019, at 12:04 PM, Stan Kalisch wrote:
On Fri, Aug 2, 2019, a= t 3:58 PM, Murray S. Kucherawy wrote:
On Fri, Aug 2, 2019 at 3= :00 AM Alessandro Vesely <vesely@ta= na.it> wrote:
Let me note that Section 3 of rfc8601, /The = "iprev" Authentication Method/,
does not contain the term "policy".

Wow.  I'm amazed I got away with that.

<= /div>
But it is clear from the things in the registry that that's ho= w you do it.

My recollection is that reporting the
client IP is immaterial, as for SPF.  The term policy.ip= rev is certainly
misleading, = since the value is not related to a locally-defined policy, and is
not a reversed ip.  To stick = with A-R semantics, it should have been named
tcp.ip, remote.ip or some such.  If a property war= rants deprecation, it's
polic= y.iprev.

The choice of "policy= " for "iprev" is rooted in history, because the earlier versions of the = document (as you well know) demanded that the things being reported had = something to do with the message itself.  "iprev" was an exception = the community chose to allow.  It pre-dated RFC5782 which introduce= d DNSxLs formally.

For guidance here, I wou= ld rely on anecdotes of implementation.  Has anyone implemented som= ething that attaches "iprev" results?
=

IIRC, Fastmail's Authentication Milter does.  But I also have= some vague recollection that they stopped using policy.iprev, specifica= lly.

Now looking at headers from my Fastmail customer acc= ount, it appears to me that this is indeed what they did, although I wou= ld have to recheck the actual distribution they share with everyone else= to be sure.  I'm sure someone at Fastmail can comment on what actu= ally precipitated the move.

We= (Fastmail) do attach IPRev results. We used policy.iprev for the remote= IP up until October 2018, although it may have been slightly later when= the change made it through to production. I recall the change being mad= e as part of a larger set of changes which came out of an ARC interop wo= rking session.
Current code uses smtp.remote-ip for a few = reasons, mostly as it is more correct to attach this to the IP to the sm= tp type, it is also more in line with what some other providers are doin= g. For context, we are using this when processing messages with a truste= d ARC set.

--

  Marc Bradshaw
=   marcbradshaw.net |&= nbsp;@marcbradshaw
<= /div>

=

--3a63167ba2794788bdb5f5eedcdd46c7-- From nobody Fri Aug 9 23:47:38 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6314B1201EA; Fri, 9 Aug 2019 23:47:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <156541965631.2092.1955861073382730689@ietfa.amsl.com> Date: Fri, 09 Aug 2019 23:47:36 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-06.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 06:47:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-06.txt Pages : 14 Date : 2019-08-09 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. Domains at which registrations can occur are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. This document also seeks to address implementations that consider a domain on a public Suffix list to be ineligible for DMARC enforcement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-06 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 9 23:49:35 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3021201EA for ; Fri, 9 Aug 2019 23:49:33 -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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=DsIBeYf5; dkim=pass (2048-bit key) header.d=kitterman.com header.b=fpltFx9F 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 lV2DWNpU0sqZ for ; Fri, 9 Aug 2019 23:49:32 -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 E735F12029B for ; Fri, 9 Aug 2019 23:49:31 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CA7C1F806CC for ; Sat, 10 Aug 2019 02:49:30 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1565419770; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=1qN0rTx0UPs8D6aaF+ijafTHcXgxHyuv3Zh1Qt+c7Sw=; b=DsIBeYf548zA3ioacjGxySRaFgdDDXxMYsuQSwS7NYPX/s4vQ7ryksCA Q40bf19pKVyIEe2PoCQ81gZWW6cDCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1565419770; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=1qN0rTx0UPs8D6aaF+ijafTHcXgxHyuv3Zh1Qt+c7Sw=; b=fpltFx9FNyRvsbM0DFeXp7IxlIKZ4mCGsL0DrDRsV3zjB8vRaj/hx5T+ QFI8N10lcIx+F6nV87pQ4JcJ7sZLYSEKdVChGkik16oz4wISH2matE4Qmy GFCHuFHMAY60yCQJ3LIkmJDgn6rNtSf6KexBy478thTJAEj1AX60v74qDS y/pG+Wk6JA6OSkRL2TOa7mk/PbYC3rjpkTp42b+kHXiuGRspvS+ARe5eis sugBMCaO6XnqmzE+ijQggSEx03jPRduksJVpQ9ISVtUsZeKZWaPTBVUMua eIx9AtYGGA+HsS/eqvjO6mEI3cE5LUJVgBiGhM3aapdSbaENxEwMrw== 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 8707DF80033 for ; Sat, 10 Aug 2019 02:49:30 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 10 Aug 2019 02:49:29 -0400 Message-ID: <3966163.57549G4C0j@l5580> In-Reply-To: <156541965631.2092.1955861073382730689@ietfa.amsl.com> References: <156541965631.2092.1955861073382730689@ietfa.amsl.com> 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-06.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: Sat, 10 Aug 2019 06:49:34 -0000 On Saturday, August 10, 2019 2:47:36 AM 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-06.txt > Pages : 14 > Date : 2019-08-09 > > Abstract: > DMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. The design of DMARC > presumes that domain names represent either nodes in the tree below > which registrations occur, or nodes where registrations have > occurred; it does not permit a domain name to have both of these > properties simultaneously. Since its deployment in 2015, use of > DMARC has shown a clear need for the ability to express policy for > these domains as well. > > Domains at which registrations can occur are referred to as Public > Suffix Domains (PSDs). This document describes an extension to DMARC > to enable DMARC functionality for PSDs. > > This document also seeks to address implementations that consider a > domain on a public Suffix list to be ineligible for DMARC > enforcement. Note the updated abstract and please review the changes to the first part of the introduction as I had to write new text there and not just incorporate msk's comments. This covers all the pending work of which I am aware. Scott K From nobody Sat Aug 10 01:44: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 62374120099 for ; Sat, 10 Aug 2019 01:44:00 -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 YsAmryBGwJwl for ; Sat, 10 Aug 2019 01:43:58 -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 CDA41120098 for ; Sat, 10 Aug 2019 01:43:57 -0700 (PDT) Authentication-Results: mail.aegee.org/x7A8hpES019056; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1565426632; i=dkim+MSA-tls@aegee.org; r=y; bh=KKLBdBvkkiflZeVhOGuRcQevlFwgm/HjrI3B5N61GZs=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=dZat8KFYeV+1tgad/ZqOI/q13qljd3GTNyllA/LKBYmWRH1qzqM9RH6meeuKr7K1j 17QBiR6/bPXuplx59lxcwQohtsXqT7zFLn0asfTn4ecQQP3NBUQrZN/C9pwoztxZ/6 J8b9Je4aHDwK0641v9WyCQQ89+kUHQvOCkcB2GV9SDXNOwRMON5Xn+KV5oljAQ2ZJu PRJe/KGn7Izcl65pwGZVoqeXlC7gpb27zj00kScXOxzYzanZtkrmKGdlUcigjz+jir qNojfE8LdfS4xCFaurmQv8k3Mod5qD0yUZR/n1e2ax8zg4Vo/+gCs5RrL7gABUZLQj IjiGCNeNnuya9QNr1YXNh2Q9tMK6/UD/fg2a2fPCWvtZN2gWeLU2jMG/cA1hTXa3KI kH+7563BH2sItIk1D2scnIQEsXgbD7E28LyaGF9AXQGGrGHd/7FzOekdpmwCNWayNg toQ9U4C6ssEHcXIciaSB1LnRBkGUrc6yJjg9ob8Wa8iSn7C6P9d2BDy8iaB/bZ+snG yPC3jykxDSElw9ubJcN6pL8hh8GUqO5ghgp5wAtjanXZGNryryF69qUlgLa7pE1X0I hIJYN6fsmmLFmUS4/WMAaAr9C6DVGS/1FHPGHd7j0t7bM/pmTlwDMMOtnGM8kYSZmC SGZ93fzN058CMrwJeWVCKsro= Authentication-Results: mail.aegee.org/x7A8hpES019056; 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 x7A8hpES019056 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 10 Aug 2019 08:43: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: "Murray S. Kucherawy" , Scott Kitterman Cc: IETF DMARC WG Date: Sat, 10 Aug 2019 08:43:51 +0000 In-Reply-To: References: <20190803030532.1D33375D900@ary.qy> <0CB7D475-6DDE-403D-BA65-E38C89A6D90A@kitterman.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.91 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.3 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] New proposed wording for p=quarantiine 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, 10 Aug 2019 08:44:01 -0000 Hello, to the idea to amend the existing definition of p=: quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". the text “ The Domain Owner wishes in addition, that the sender of messages failing DMARC are notified about the suspicious handling with an appropriate rejection message. Senders not willing to be notified that their message is suspicious, shall use the NOTIFY=NEVER service extension. In the past, Domain Owner could express as wish either to reject or to quarantine. Considering that from the options: only reject; only qurantine; and quarantine, while notifying the sender about the suspicious handling of the message; nobody will choose only to quarantine, the interpretation of what the Domain Owner wishes by publishing quarantine was changed to include the rejection component.” so far two voices were against. The reasoning against the amendment is that writing what the domain owner wants is just its preference, not anything binding, and the current definition is sufficient. My motivation in favour the amendment is, that currently nobody has the practice to quarantine messages and inform the sender of the special delivery status at the same time. Spelling more precisely what the domain owner wants will suggest the implementations to implement precisely that preference. With other words, the sole reason why a receiving host does not notify the sender for quarintined message might be, that the receiving site has not come to this idea. The additional text removes the cause. If there was a common practice by now to deliver as junk and reject with appropriate text at SMTP level, then the amendment would have been less necessary. Regards Дилян On Wed, 2019-08-07 at 08:13 -0700, Murray S. Kucherawy wrote: > On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman wrote: > > Policy is an indication of sender preference, not a directive the receiver must follow. I think the definition is fine. If the sender prefers failing messages be quarantined, then they should use that policy. They won't get what they want in all cases and that's fine. > > This matches my understanding. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Aug 10 02:14: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 061161200BA for ; Sat, 10 Aug 2019 02:14:07 -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 e4CP0qlzq7HM for ; Sat, 10 Aug 2019 02:14:06 -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 80EF1120058 for ; Sat, 10 Aug 2019 02:14:05 -0700 (PDT) Authentication-Results: mail.aegee.org/x7A9Duro025182; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1565428442; i=dkim+MSA-tls@aegee.org; r=y; bh=+TmO1EYukcx0CI8P3cl9IvbvvNdFvX28TboTe5Zp8Bk=; h=Subject:From:To:Date; b=pdrjqqM1jV+Xs8k6ZzNqZSCXjL3t5fDnTMP9+FvGIqOaHVmAmR58X9AW75qGM6drN /TEghgssoae5nQkG4IABSepMibyE0ufTdpvLVpz5OYPoHqeDgNk742OxAgddch5ZdH xV16eb2TAIqqcZb4bH0xuIRInMoLJ1pi27vYSJEJ5qgib/ZWJiPjLR4tu9AZZJMkJV vxdp4Jb4SkFmhVrnigI3V3ZM7VPb8m1Ao6qp5SHKsivb6TgoiySkra4Tge4IY4Y6Xi YDpPWT7PUnjNSd5WTLwnhxC6f5YMVy9fyqao1hZj5Pb34XLIYyrVdNYQkOmU15m8da V/g68hlbXKv2jXkmglh5OAFxX6f6XL8UMft/nHSEfg+fUu3Mq9vD7FtbmwYhmF9Xq9 IS7KjOiQFmnOGWiXPTAuwdA9z646J6H93VPvwDJMCCppZy6N8D4JHdtZABmp2hlKTl GeS/rezM/y1ZmI56uulOXLjgKa/G4qUE/Yiy4VqK1bqJWTn+B10nmwzOLc5JX8rKKF DwGNn7cjfTZ/YjiCMvPTQefkKdELyqdNZ624TSKkt4QLo45xDnLeHCrsrKuArjkfuP p+TX2I8La2ubEyqf8uTNDjfFaXl2B8iEpZSKr/c47ibSetddUDYI+fHvx0D7TC7x0a 4jyCyWRCwClcU48vNGc+zlAc= Authentication-Results: mail.aegee.org/x7A9Duro025182; 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 x7A9Duro025182 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 10 Aug 2019 09:13:56 GMT Message-ID: <2e2e9fa0a4da92b5d02a41a803e9947f6c562696.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: dmarc Date: Sat, 10 Aug 2019 09:13:55 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.91 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.3 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] Purposes of aggregate and per message failure 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, 10 Aug 2019 09:14:07 -0000 Hello, the purposes of the reports shall be first articulated and then the content of the reports shall be augmented to fulfil the purposes. * * * Purpose of Aggregate Reports * * * Some purposes are clarified in the email from Michael Hammer/2019-07-31: “ Having both passes and failures is incredibly useful. The percentage of failures is very useful. Any set of mail streams will always have some failures. Once you know what the baseline rate for a (sub)domain is, simply seeing changes in that rate will help you identify problems.. An increase in the failure rate is generally either 1) someone trying to abuse your domain name; or 2) something has gone wrong with DKIM signing or someone associated with the domain organization has started sending mail from somewhere without appropriate SPF or DKIM.” -- The email from Tomki/2019-06-21: “ 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” Once the RSA-SHA256 signatures between two sites function properly, the aggregate reports do not allow to verify, that the ED25519 signatures also work correctly. Thus two sites exchanging emails cannot know, if switching to only ED25519 signatures will work reliably. With this in mind, a new purpose of the aggregate reports is to allow for two sites, having proper RSA-SHA256 implementations, to verify, whether the ED25519 implementations are also correct. -- For what purpose the envelope sender is communicated? My understanding of recent communications is, that this information is exchenged, I do not reread the specification now. * * * Purpose of Per Message Failure Reports (also known as forensic report) My understanding for the purpose of the failure reports is, that these can serve only one of two purposes: * Either verify whether the DMARC/DKIM implementations of sender or receiver match, * Or spread information about scammer actions (The concerns for not sending failure reports for privacy reasons are only for the second case. The concerns about not sending reports in the first case is about silencing improper DMARC implementations). The case, where the implentations match, but the sender forgets to sign messages from its servers, is uncovered by the aggregate reports, and for fixing this case, the aggregate reports provide sufficient information. Regards Дилян From nobody Sat Aug 10 03:36:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C1E120123 for ; Sat, 10 Aug 2019 03:36: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 XbEtWi-wBJh5 for ; Sat, 10 Aug 2019 03:36:49 -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 E001E12024F for ; Sat, 10 Aug 2019 03:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565433404; bh=bGp7zP82o4EpTH11UhNo6v6npQ2DyuQFOcejdE3eIuM=; l=2807; h=To:References:From:Date:In-Reply-To; b=DgZJji4NVn8g1uiD07UrNTQbsrUbgpCBFeToMPGzhSSYMV0UaNkv+Ig0dT/89yTbd GU/5od2CR16OZQN5P/Bcn+kdWIAIzEkVQ3hNdqUueVpB7Xf1RWR7C5AwAemihaCBCy 0hOn4toBRwg3CJ50gBXRyGCPtCrwGTpoJewSOuSj9IUFVtOdCQKHvvnJyFhUz Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.101] ([5.170.70.93]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.000000005D4E9E3C.0000677B; Sat, 10 Aug 2019 12:36:44 +0200 To: dmarc@ietf.org References: <156541965631.2092.1955861073382730689@ietfa.amsl.com> <3966163.57549G4C0j@l5580> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <6c3a1ccf-01b3-a073-65c4-f00001729f47@tana.it> Date: Sat, 10 Aug 2019 12:36:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <3966163.57549G4C0j@l5580> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-06.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: Sat, 10 Aug 2019 10:36:55 -0000 On Sat 10/Aug/2019 08:49:29 +0200 Scott Kitterman wrote: > Note the updated abstract and please review the changes to the first part of > the introduction as I had to write new text there and not just incorporate > msk's comments. This covers all the pending work of which I am aware. The intro looks smooth. Perhaps, for maximum clearness, you could add a sentence after the first one of the second paragraph: As an example, imagine a country code TLD (ccTLD) which has public subdomains for government and commercial use (.gov.example and .com.example). They are both on the public suffix list, although gov.example is not really available for public registrations, domains under it belong to different branches of the government. Suppose there exists a registered domain "tax.gov.example" that is responsible for taxation in this imagined country. [...] Excuse me, but I hadn't noted the following in Murray's message of Aug 1st: Experience with DMARC has shown that some implementations short- circuit messages, bypassing DMARC policy application, when the domain name extracted by the receiver (from the RFC5322.From) is on the public suffix list used by the receiver. This negates the capability being created by this specification. Therefore, the following paragraph is appended to Section 6.6.1 of DMARC [RFC7489]: Note that domain names that appear on a public suffix list are not exempt from DMARC policy application and reporting. First, it's not easy to read, as the concept of PSL "used by the receiver", albeit obvious, is new. The whole idea is better expressed by the last three lines in the abstract. Second, Section 6.6.1 of RFC 7489 deals with the uniqueness of the From: domain. The idea of a PSL is brought forward in a subsequent section (policy discovery). If the note has to go there, I'd rather insert it between the first and the second paragraphs of that section. The last paragraph there seems to conflict with the second bullet, and adding the note above after it is not going to make things clearer. The next section has: As an example, for a message with the Organizational Domain of "example.compute.cloudcompany.com.example", the query for PSD DMARC would use "compute.cloudcompany.com.example" as the longest PSD (Section 2.3). The receiver would check to see if that PSD is listed in the DMARC PSD Registry, and if so, perform the policy lookup at "_dmarc.compute.cloudcompany.com.example". It is not natural to spot which is the organizational domain, because the names are misleading. Cloudcompany looks like a name registered under the com.example PSD; how come compute.cloudcompany.com.example is the longest PSD? I'd stick with the gov.example introduced earlier. jm2c Ale -- From nobody Sat Aug 10 08:07: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 8C53B120043 for ; Sat, 10 Aug 2019 08:07:53 -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 4_tBRClXjM5i for ; Sat, 10 Aug 2019 08:07:50 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918B212001A for ; Sat, 10 Aug 2019 08:07:50 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id s3so8396585wms.2 for ; Sat, 10 Aug 2019 08:07:50 -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=utbniqjTAymfjc/m2qNwmlJZQKpWcRcwl94Dx8+NLX0=; b=sIKRbza87Db7VqCNGprEBrIazlsfccwaODCX2/ByiHc8ZosXXldV7iA7vs5iGNv2t7 xCSzFklYxubpNuRCdIu0GCy+DDSG4/3sdhUKScmqGPNpqNk8Jz1WguZsq5yct4ZDLOSM OdD7SRA7jlLbxSezUQrDhkvM9MW9424H6uQx2t/I47Z19+rWWNNwkadjMDal9hgpZF4s qbvJTFNjMu4voOrf5VrcVCaOUID/SDnKxaI6VQ2nVUXyN8PTdX6+e86vNCnxhqUAQtYP vUQtLWUORHzyTA079l7D5U2FTMRjOqC0oksLBd5UOphn0lsILCYyN+GJT6j+GI98fqx8 iGEA== 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=utbniqjTAymfjc/m2qNwmlJZQKpWcRcwl94Dx8+NLX0=; b=GbwVt1AhbTbjLGRs5+qJryTHKU+6oehRGVNkjD4n+GQ3SkDGZIJjr4oqZEYXKEo+1q J3eSx53r2vARUMXKTx6P9KMVLHaYx/id4YDROW3IfsQm6a44gl+2xpa+IU7xONCCnClz 09c/lx9/rdFyeHeVBK/rucoz6QwTf8HXedgma3R3TZfduZCOybvneFt5QC55VCEgqKsW CUbtZx1NjwXhlvV8deK8zniIRG2y/dZufvYbrkuV+oWudURCv8Cnmc1yVnplE8DonwiM WtoNGKsnHSLhuj2c5Vc7KOSG3A9KHwIdJH4z4HtTZUyNrZKYRc+HvyfcJhyfMVDbNAOe qfFA== X-Gm-Message-State: APjAAAU/vjgvlO6tDfA6vUcEvVmk+65G49vhHfiWCvUiGgDIS/mtNc+M xeQ6e9Qbva51hd4mWPT5G8PVO2yVP4oIKbC8VPs= X-Google-Smtp-Source: APXvYqwITq2wkEz/P32bpGNJVzASonIcIFqrkzcggbCSFIqH8rjVGWtWvD5dMqw11Tf9K/VgvZvgZyjAhL1O1ZQekKc= X-Received: by 2002:a1c:751a:: with SMTP id o26mr17191328wmc.13.1565449669102; Sat, 10 Aug 2019 08:07:49 -0700 (PDT) MIME-Version: 1.0 References: <20190803030532.1D33375D900@ary.qy> <0CB7D475-6DDE-403D-BA65-E38C89A6D90A@kitterman.com> In-Reply-To: From: Dotzero Date: Sat, 10 Aug 2019 11:07:38 -0400 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: "Murray S. Kucherawy" , Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000070d01f058fc4a72e" Archived-At: Subject: Re: [dmarc-ietf] New proposed wording for p=quarantiine 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, 10 Aug 2019 15:07:54 -0000 --00000000000070d01f058fc4a72e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 10, 2019 at 4:44 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: > Hello, > > to the idea to amend the existing definition of p=3D: > > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check be treated by Mail Receivers as > suspicious. Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > > the text =E2=80=9C > > The Domain Owner wishes in addition, that the sender of messages failing > DMARC are notified about the suspicious > handling with an appropriate rejection message. Senders not willing to b= e > notified that their message is suspicious, > shall use the NOTIFY=3DNEVER service extension. > > In the past, Domain Owner could express as wish either to reject or to > quarantine. Considering that from the options: > only reject; only qurantine; and quarantine, while notifying the sender > about the suspicious handling of the message; > nobody will choose only to quarantine, the interpretation of what the > Domain Owner wishes by publishing quarantine was > changed to include the rejection component.=E2=80=9D > > so far two voices were against. The reasoning against the amendment is > that writing what the domain owner wants is just > its preference, not anything binding, and the current definition is > sufficient. > I'll add a third voice. When we came up with DMARC - yes, I was part of the original dmarc.org team - we were extremely cognizant of the fact that there is no way to bind receivers/validators to the preferences expressed by senders. The whole purpose of DMARC was to take something that was working through private contractual agreements in a private group and make it available more generally and publicly. Today there are receivers which only make reporting available on a contractual basis through 3rd party intermediaries or because there are direct relationships between the sender and receiver. It is important to recognize what is required for interoperability (in a standard) and what is a want that goes beyond what is appropriate for a standard documenting technical interoperability. > > My motivation in favour the amendment is, that currently nobody has the > practice to quarantine messages and inform the > sender of the special delivery status at the same time. Spelling more > precisely what the domain owner wants will > suggest the implementations to implement precisely that preference. > > With other words, the sole reason why a receiving host does not notify th= e > sender for quarintined message might be, that > the receiving site has not come to this idea. The additional text remove= s > the cause. > Technical standards, as a general rule, should not be written based on suppositions with regard to hypothetical causations that lack any empirical evidence to support those suppositions. One could just as easily suppose that the reason that receiving hosts do not notify the purported sending domain is that they believe it is a bad idea. In either case it is a supposition without any validation. We are not mind readers. > > If there was a common practice by now to deliver as junk and reject with > appropriate text at SMTP level, then the > amendment would have been less necessary. > > You are asserting the amendment is necessary but you are providing no data to support your assertion. My experience covering a corpus of billions of emails does not support your assertion. I therefore agree with Scott and Murray that no amendment is appropriate in this case. Michael Hammer --00000000000070d01f058fc4a72e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Aug 10, 2019 at 4:44 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 <dilyan.palauzov@aegee.= org> wrote:
Hello,

to the idea to amend the existing definition of p=3D:

=C2=A0 quarantine:=C2=A0 The Domain Owner wishes to have email that fails t= he
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DMARC mechanism check be treated by Mail = Receivers as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suspicious.=C2=A0 Depending on the capabi= lities of the Mail
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Receiver, this can mean "place into = spam folder", "scrutinize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with additional intensity", and/or &= quot;flag as suspicious".

the text =E2=80=9C

The Domain Owner wishes in addition, that the sender of messages failing DM= ARC are notified about the suspicious
handling with an appropriate rejection message.=C2=A0 Senders not willing t= o be notified that their message is suspicious,
shall use the NOTIFY=3DNEVER service extension.

In the past, Domain Owner could express as wish either to reject or to quar= antine.=C2=A0 Considering that from the options:
only reject; only qurantine; and quarantine, while notifying the sender abo= ut the suspicious handling of the message;
nobody will choose only to quarantine, the interpretation of what the Domai= n Owner wishes by publishing quarantine was
changed to include the rejection component.=E2=80=9D

so far two voices were against.=C2=A0 The reasoning against the amendment i= s that writing what the domain owner wants is just
its preference, not anything binding, and the current definition is suffici= ent.

I'll add a third voice. When w= e came up with DMARC - yes, I was part of the original dmarc.org team -=C2=A0 we were extremely cognizant of the fact= that there is no way to bind receivers/validators to the preferences expre= ssed by senders. The whole purpose of DMARC was to take something that was = working through private contractual agreements in a private group and make = it available more generally and publicly. Today there are receivers which o= nly make reporting available on a contractual basis through 3rd party inter= mediaries or because there are direct relationships between the sender and = receiver. It is important to recognize what is required for interoperabilit= y (in a standard) and what is a want that goes beyond what is appropriate f= or a standard documenting technical interoperability.

My motivation in favour the amendment is, that currently nobody has the pra= ctice to quarantine messages and inform the
sender of the special delivery status at the same time.=C2=A0 =C2=A0Spellin= g more precisely what the domain owner wants will
suggest the implementations to implement precisely that preference.

With other words, the sole reason why a receiving host does not notify the = sender for quarintined message might be, that
the receiving site has not come to this idea.=C2=A0 The additional text rem= oves the cause.

Technical standards, as= a general rule, should not be written based on suppositions with regard to= hypothetical causations that lack any empirical evidence to support those = suppositions. One could just as easily suppose that the reason that receivi= ng hosts do not notify the purported sending domain is that they believe it= is a bad idea. In either case it is a supposition without any validation. = We are not mind readers.
=C2=A0

If there was a common practice by now to deliver as junk and reject with ap= propriate text at SMTP level, then the
amendment would have been less necessary.


You are asserting the amendment is nec= essary but you are providing no data to support your assertion. My experien= ce covering a corpus of billions of emails does not support your assertion.= =C2=A0 I therefore agree with Scott and Murray that no amendment is approp= riate in this case.

Michael Hammer=C2=A0
--00000000000070d01f058fc4a72e-- From nobody Tue Aug 13 19:02:09 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 75FFB120018 for ; Tue, 13 Aug 2019 19:02:06 -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, 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 MMd7v9lzDnhB for ; Tue, 13 Aug 2019 19:02:03 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3FA12001B for ; Tue, 13 Aug 2019 19:02:03 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id f17so43428584otq.4 for ; Tue, 13 Aug 2019 19:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=ve6/LJPEi1ElYKtDkN9k3LBBpQE10146zdcL9ToyH0o=; b=gdxYPCZ7CfXdrCo/71ufdEAjZpyUFaWdYpdMmCPfy57HQSWacTp87U19HLyrIvta78 RoPrHbub1KbAVvhbFITk/CjX0z03G/hPVJTDJdA4nweJFam5Y+x9GuxZN1YUxNS6yEU1 cYishasYenAY4dDfkShHE4x1DdR/myUTXbV6Lomw3lXy8KBCX8Hbj2bS7EZYdd9MeX94 86+APVcCq/So5R3jIofpHPw9dBXa3opQ6tgxPj7spiSQPD/4zaL7KNPPdGJtc4kuVf6I s5g1jentlGii8/k8G0C+f+2mSZ3laWZNoaAvq+Jbrq7T3Ad9kgzkxaHVLb8E9lWa6nIK JpAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=ve6/LJPEi1ElYKtDkN9k3LBBpQE10146zdcL9ToyH0o=; b=ZQ2gzxz82vBqgM4sdT+YIJSB8K5QyxCkVEW5EBs1LO4QLWxLEN5f666bFY30vAvl7b LKgsWyz5sICeKd1vZt7+BsB7fEM3ptwoHcsPKlxZTG8Cq7DjwVlZCAid6L/1lpOynadF if2ANYhSe073WNu5O/5bozTDqzvo+fBGC99yTCuNNVkE2XcW5+rqD3xj+WTvtPdVel7s t/EBEz7v2+bC3wsh6PEiSEWFNY+/X02cwsrbHSDAjqt84bv0jMhjzOQ8Ou9CUtlFDNER kfH1eMZdhKuR4n5lAO7hUO1YjJk+xL7yyJvhomxfpA2QUTNfV4FHgGuCVzAazYIVVbx0 oY5w== X-Gm-Message-State: APjAAAXMEmKOna4WFdnggm48SA2d03jhAderkBau4uKBHo4QDDm/7e8T mI9IZNi9UxxbQJsQY2wG/H8i7KaF X-Google-Smtp-Source: APXvYqyzwwz03O0lHHXOnsRjqj+Hbt0aghem1IWZ4M2VO14uuPTNOWY6hnKhCfrElYSo8i6lqAD5bQ== X-Received: by 2002:a9d:ee9:: with SMTP id 96mr15681169otj.215.1565748121481; Tue, 13 Aug 2019 19:02:01 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:b832:158e:a812:daf6? ([2600:1700:a3a0:4c80:b832:158e:a812:daf6]) by smtp.gmail.com with ESMTPSA id v1sm5969199ota.60.2019.08.13.19.02.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 19:02:00 -0700 (PDT) From: Dave Crocker X-Priority: 2 (High) To: IETF DMARC WG Message-ID: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> Date: Tue, 13 Aug 2019 19:01:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 02:02:07 -0000 Review of: DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) I-D: draft-ietf-dmarc-psd-06 Reviewer: D. Crocker Review Date: 12 August 2019 The draft specification's intent is to address a basic operational limitation in the current use of DMARC. There are domains in the upper-reaches of the DNS space that are not accessible for obtaining organization-wide policy records, but which need to become accessible. Per the PSD draft: > For domains listed in a public suffix list, i.e. 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 > these domains to express policy or receive feedback reporting for > sub-domains. Background ---------- The operational history is that the upper reaches of the Domain Name System have been restricted to administration by organizations that all strictly served as constrained registries. Their domain names were allocated by ICANN or by another public agency (such as a government). They all were distinct as organizations registering sub-domain names for other, independent organizations. Unfortunately there is no algorithm that can distinguish between these public registries from their sub-domains; hence they must be manually determined. In the DMARC specification, the aggregation of these registries is referred to as a "public suffix list", after the primary Internet service offering such a list. The term 'public' here is mostly taken to mean that the registry for such a domain operates as a public service.(*) DMARC's use of a public suffix is to permit finding the "organizational domain", which is the domain name that is delegated from a public suffix registry and is the name highest up a branch while having the same administrative authority as the full (DMARC "aligned") domain name being evaluated by DMARC. The next-higher domain name above the organizational domain -- a public registry -- is under separate operational authority. DMARC needs to know the organizational domain so that the organizational authority can assert a DMARC policy for all subordinate domains, notably those that do not publish their own DMARC record and domains that do not exist. This capability overcomes a downgrade attack on DMARC, where an organization's intent to have all of its subdomains subject to DMARC evaluation can be bypassed by using a name that does not have an associated DMARC record. The focus on these two terms is important to highlight. They refer to the operational role of the domain name. A Public Suffix serves as a public registry. An Organizational Domain operates as a 'master' authority over a branch of related names. While the popular public suffix listing example is cited, a specific public suffix list is not normatively incorporated into the DMARC specification: That is, there is normative use of 'some' public suffix list, but no normative details for choosing it. Determination of what is a public suffix and what is not is, therefore, outside the scope of the DMARC specification. This is a very useful separation of functions, especially given operational concerns about the status quo for public suffix determination. Decoupling moves those concerns away from DMARC, per se. This both simplifies the DMARC specification and improves its stability, since it does not have to change when details of the public suffix functionality changes. However there is now a requirement to extend DMARC's ability to assert an organizational policy record to include names in the upper levels of the DNS, which have classically been viewed as public suffixes. Indeed, the draft specification calls them public suffixes. Historically, domain names listed in these upper levels did not participate in the assertion of DMARC policies for their sub-domains. Now, some of these domains want to. Specifically, some upper-level domain names need to be able to publish a DMARC record that asserts a policy for all sub-domains under them, in particular to cover domain names that do not exist or that have not published a DMARC record. This requirement even applies to some top-level domains. That is, names that are typically classed as 'public suffix' names need to operate as 'organizational domains' for DMARC. Draft PSD Specification ----------------------- The PSD draft seeks to address this requirement. Within the DMARC sandbox, it is important to have a way to communicate a domain owner's DMARC policy, for sub-domains that do not exist or do not publish a DMARC record directly. For upper-level domains, the draft does this by introducing an additional query, to the domain name that is one level higher than the determined organizational domain. The perspective of the draft is that it is adding a query into a portion of the public suffix list. This approach is problematic in several ways. It is a substantial increase in DMARC's operational overhead. It adds a query that will often be needed -- especially in the face of limited DMARC adoption. If a domain is not already a 'popular' DMARC reference -- that is, frequently encountered by the querying site -- it is likely that there will be no DMARC record for any of the three needed queries. That means a 50% increase from two (failed) DNS queries to three (failed) queries. By it's nature, this mechanism will succeed for only a tiny percentage of domain names that are used. (Given common locality of reference, a particular site might see quite a bit of name re-use, so that the statistics for their actual traffic might be quite a bit better than the theoretical 50% increase.) So PSD it will likely provide at best a tiny benefit, relative to overall DMARC use. Note: all receivers must support this feature and incur its relatively large overhead, while virtually never seeing the extra query be successful. So the cost/benefit incentives are quite poor for receivers. From a design standpoint, the specification also is problematic. Added mechanism is added complexity. And the reality of Internet standards is that the cost of added mechanism is disproportionately large. Think exponential rather than linear, due to the accrued cost of implementation, testing and deployment. Besides adding complexity, it breaks the technical separation between DMARC and public suffix, by diving into that space. Hence the PS in PSD. Remember that the reason for wanting to query the organizational domain is to check for a policy record that applies to all sub-domains. That is, the record being sought is authoritative for the branch below it. The proposed enhancement seeks to look for a 'more authoritative' domain name above the one that has been classed as an organizational domain. Adjusting Perspective --------------------- Of the new set of domain names being targeted for publication of a covering policy record, there really are two types of administrative roles they serve. One is exactly the same as the classic organizational domain: A top-level domain that is registered for an organization, to be used by the domain owner directly for itself. This really is exactly the same as DMARC's classic construct of organizational domain. For example, *.example.com and *.example can both be classic (private) organizational domains. It doesn't matter that one might be delegated by a classic public registry and the other by ICANN. The actual use of the allocated name is as an organizational domain. The second use can be called as "association domain". The containing name covers a set of sub-domains referring to member organizations. Besides applying to groups that might be obviously classed as associations -- such as industry trade groups -- some large organizations are operated with enough independence among its subordinate departments or subsidiaries to make tight control unrealistic. A salient example of this is a government and its 'subordinate' departments. Arguably for DMARC purposes, an association domain can be treated the same as an organization domain, since the scope of the domain's authority over its sub-domains is an internal matter, to be determined by its agreements with association members. What this means is that the real requirement here is to improve the mechanism for identifying the organizational domain, and that requirement is outside of DMARC. This does not reduce the necessity of identifying these domains; rather it moves the task to where it belongs: This requires modification to the public suffix list operation, possibly with a parallel "private TLD" registry. An added benefit to this alternate view is that it eliminates the privacy concern about the draft specification: only upper-level domains operating as organizational domains will be able to publish a domain-wide DMARC policy record. Domains that really are classic public suffixes won't be able to. (Merely for completeness I'll note: Some upper-level domains have ICANN-based restrictions on what records they can publish. As has been discussed in the working group, although obviously essential to resolve, this issue is entirely outside direct work on DMARC.) Summary ------- Independent of DMARC, develop a method of identifying the upper-level domains that need to be treated as organizational domains. The "public suffix" for these domains is whatever portion of the name is to the right of this, as usual. (The current draft's Appendix B might seem reasonable for this, but note that it formally has nothing to do with DMARC, per se, and it probably has some interesting administrative challenges. In any event, it is augmenting the existing Public Suffix List rather than DMARC.) The modification to DMARC, then, is to allow this 'suffix' part to be empty, in order to support top-level domains that operate as organizational domains. This produces zero change to DMARC's lookup behavior and almost no change to its specification. d/ (*) Public Suffix List -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Aug 15 03:20: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 DE475120094 for ; Thu, 15 Aug 2019 03:20: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=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 sXB0lqYhzolO for ; Thu, 15 Aug 2019 03:20:18 -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 46184120072 for ; Thu, 15 Aug 2019 03:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1565864415; bh=NZwk4AXoXA+42wdiz6OQffO9xMje+L74qw9zp6bRm3M=; l=3429; h=To:References:From:Date:In-Reply-To; b=DVyciW3kgV9P1EgA3/J2FAABA3i1xlRgkLsTS9Z2MfpFIuX9FaxjltYnwOTz8juCe eC/vWr1nGLRPNo7hwhRVjhKckfz1tip+6HnyYvC0N9Yx1SCcBQ3mzo6QE49wZSsnZ7 rEORkfeA+FUZ+gI2ERjx5062P7ti0azTWYN983XBhmk5n7WGzmMSvhhkLgUUW Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.70.68]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC042.000000005D5531DE.0000501D; Thu, 15 Aug 2019 12:20:14 +0200 To: dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Thu, 15 Aug 2019 12:20:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 10:20:20 -0000 On Wed 14/Aug/2019 04:01:59 +0200 Dave Crocker wrote: > > > Review of:    DMARC (Domain-based Message Authentication, Reporting, and >               Conformance) Extension For PSDs (Public Suffix Domains) > I-D:          draft-ietf-dmarc-psd-06 > Reviewer:     D. Crocker > Review Date:  12 August 2019 I like very much Dave's prose, especially the background. I hope large fragments of it will make their way to either the PSD draft or the reviewed DMARC spec itself. For brevity, however, I only quote the passages I comment on: > This approach is problematic in several ways. > > It is a substantial increase in DMARC's operational overhead.  It adds > a query that will often be needed -- especially in the face of limited > DMARC adoption.  If a domain is not already a 'popular' DMARC > reference -- that is, frequently encountered by the querying site -- > it is likely that there will be no DMARC record for any of the three > needed queries. That means a 50% increase from two (failed) DNS > queries to three (failed) queries. That's actually a bit better. After the second (failed) query, the receiver consults the "augmented PSD". IMHO, the latter should be a local lookup, just like the PSD itself. The third query is only issued if the prefix matches. Then, the likelihood that it fails is very low. > Arguably for DMARC purposes, an association domain can be treated the > same as an organization domain, since the scope of the domain's > authority over its sub-domains is an internal matter, to be determined > by its agreements with association members. > > What this means is that the real requirement here is to improve the > mechanism for identifying the organizational domain, and that > requirement is outside of DMARC.  This does not reduce the necessity > of identifying these domains; rather it moves the task to where it > belongs: This requires modification to the public suffix list > operation, possibly with a parallel "private TLD" registry. Right. However, consulting the augmented PSD still has to be done in two steps, the first one to give the organizational domain a chance to override the association domain policy, the second step if no override was published. Let me add that the relevant case is NXDOMAIN. For existing domains, the association can see if a lazy organization misses a record and force them to comply. However inconsiderately, the association could even publish itself a txt record at _dmarc\.lazy.example. The annoyance is trying wildcards to cover any non-existent domain name. > An added benefit to this alternate view is that it eliminates the > privacy concern about the draft specification:  only upper-level > domains operating as organizational domains will be able to publish a > domain-wide DMARC policy record.  Domains that really are classic > public suffixes won't be able to. Certainly, A.bank and B.bank shall not be conflated as far as exchanging cookies and access rights is concerned, so a fine-grained PSD will continue to exist. I'm not sure flattening that structure for DMARC is a benefit. By skipping the second query, we'd deny organizations the possibility to have subdomain email addresses like manager@branch.A.bank, unless branch.A.bank either replicates or overrides the DMARC record of A.bank. Best Ale -- From nobody Sun Aug 18 00:34: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 8F011120026 for ; Sun, 18 Aug 2019 00:34: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, 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=leemankuiper.nl 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 anGtWlldsepG for ; Sun, 18 Aug 2019 00:34:35 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 2A7A312001A for ; Sun, 18 Aug 2019 00:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GtFNdybKrcBetPCCRcqDYWUjFxgbNWc5wsrrJ1CLA4M=; b=PLACnXC0tgEHFftDkSAGyiRm2z 1dBu7fj275VfAfo9XF2yxIYTjkB0xOe9/ekC+j8uUa2c5o6zgo76gPa3qv/QLmNiNAAmGQ3b+wDFt +CM73uONlcDe0tHne2gcvNSqdCUteyUMyBfuTT3mzx4TEzzKvqv3qexT8b14OItXcWuzjXmeqZqj8 0B6LsOhP8S2c07+WhJ6/YZ7kV6ZA40uTyeUHVptPWSmz2nKC5sOiUaTX/TkGowZnawB8jkMj8fgtk zowk8mi9Vm/siLoAwVmTCmZjQ3lY7U6Igd8tqr/db+y3EEMl3Ja3qBuz95OnrV1pK5ZQliCaBxjL+ EV0QyAgg==; Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from ) id 1hzFhw-0005gK-MF; Sun, 18 Aug 2019 09:34:32 +0200 From: "Freddie Leeman" To: "'Alessandro Vesely'" , References: <00ba01d54ca3$69ffce10$3dff6a30$@leemankuiper.nl> <134ba01d54de8$34b61fc0$9e225f40$@leemankuiper.nl> In-Reply-To: Date: Sun, 18 Aug 2019 09:34:32 +0200 Message-ID: <020701d55597$60c789d0$22569d70$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIfy2mjUVHj61yfYSQzm4Ru5o3Q/gIey5pWAOfLFGSmU2HTkA== Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: freeman Archived-At: Subject: Re: [dmarc-ietf] Should 'undeliverable mail' be included in DMARC rua 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: Sun, 18 Aug 2019 07:34:38 -0000 >> - Element's minOccurs stays 1 and =E2=80=98null reverse-path=E2=80=99 = messages get an empty 'envelope_from' value > This option is easy to grasp, as it parallels SMTP's mail from:<> After some thought I think this would be the best solution. Not omitting = the element, keeping the MinOccurs '1', but allowing the value to be = empty for null reverse-path messages. I will adjust Appendix C with = these guidelines for now. -- Freddie From nobody Sun Aug 18 11:01:34 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 39E74120059 for ; Sun, 18 Aug 2019 11:01:33 -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, 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 ZvpnKl32N3HJ for ; Sun, 18 Aug 2019 11:01:31 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 D116B12002E for ; Sun, 18 Aug 2019 11:01:31 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id r20so14043776ota.5 for ; Sun, 18 Aug 2019 11:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=63BoxoA85SRTbD7kzyckYzdM0aOPj0Bt6iBQDDZvu/E=; b=EUZNi8A2+cdXNNnNgthi6wqj0DAN1wr4aUZYf7tgwlfb05mDjHpyGaNTzOTT2r3MhZ YtnRA3mJHRMvp83GDINek5BOI5O7EGShoA+gc4+dlQ5xGOpok63pYJsgDLD2AlczPmcl MchsvlotfMFi3ohSp3vbQ2/8q0BjJy6joxj4isFcBgNwwxgjOrvgyYZusA92DPkO0DBR H0OUWQL+WUbp+agrBcKZAKxwVbi+86agnRVFfJpoz0e1qutJNwuD8ksvb4XW2/CGzxGt J2LhWdFLv8MI8bsB9mP+ADP23n7zUtybYOFFsoFyARfUe8AkvAuZA3uwu554ccCM5wp7 tLrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=63BoxoA85SRTbD7kzyckYzdM0aOPj0Bt6iBQDDZvu/E=; b=be1MMYGOAIiAlaD57wXfhdJzM9MJpWC1llUMahAci/oPaD+g7Kwl0/HR2i0QmgobFF ypv4nLkWpYdt4GLPpNYVb02o8z7QydwMHNJ6g32EyPFUPECBN0X2/XsZqSSz5dZqZ56K 7GJRIkw64qP8RhujcV1YAyuJaw62eGKpC3Qgfvh3klHqIobVuUaXv+LE9xUliDbZIQlP F6mXVShX2P25ZwrNv8FNWKh2mFWVknldZWjawGgZ8gkud1BrEuUzkU9xXoERCK+OM3aR yhP9a2n8z9z9ebPLDhdUt1lS9CjOjkd6uBv8ijohBrxmKZOfSMpFsFxL7rKq4l3CASPp yA2w== X-Gm-Message-State: APjAAAV4AuzObqbqK03lTK5v1iFRQHHTLLA2kFKpkMlI9UNzsjgi2ctj 9xOfgZKhboviG1vh2/0N4A0PMlNC X-Google-Smtp-Source: APXvYqwZPn132T/rySSo77Hl6y5abjaZnI6L3WE2018TBySNB1+lObJsdqxQzARk1DALa0LaQccyRw== X-Received: by 2002:a9d:851:: with SMTP id 75mr16147413oty.341.1566151290746; Sun, 18 Aug 2019 11:01:30 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:592d:6d9b:109f:2f? ([2600:1700:a3a0:4c80:592d:6d9b:109f:2f]) by smtp.gmail.com with ESMTPSA id a1sm4425439otl.66.2019.08.18.11.01.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Aug 2019 11:01:29 -0700 (PDT) To: Alessandro Vesely References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> Cc: dmarc@ietf.org From: Dave Crocker Message-ID: Date: Sun, 18 Aug 2019 11:01:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 18:01:33 -0000 On 8/15/2019 3:20 AM, Alessandro Vesely wrote: > I hope > large fragments of it will make their way to either the PSD draft or > the reviewed DMARC spec itself. Thanks for the kind words, but they actually run counter to the larger message I meant to impart: The entire PSD approach is problematic. This is not fixable. A different approach is needed. Making the draft Experimental is actually counter-productive, in that regard. It puts a stamp of IETF approval. The fact of Experimental is less significant than the fact of an IETF consensus stamp of encouragement. There is also the small matter of a small (actually tiny) base of demonstrated support for this proposal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 20 16:08: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 3183A120106 for ; Tue, 20 Aug 2019 16:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-L2H_Z0hw7O for ; Tue, 20 Aug 2019 16:08:51 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 D06F61200D8 for ; Tue, 20 Aug 2019 16:08:50 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id b20so123074vso.1 for ; Tue, 20 Aug 2019 16:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5JcPzuv+KudXcN4V7g/TzHoOBmzTOzWz3LCKTQiHoWQ=; b=IZAU6NP3qHurSTq/vdUP8aesxkWcaO0aKdM/3uCY+ssiX61EE7JSCkdhWO2R+mSQy+ 2m1Kv06/ClJqcPomJZg8K6C6+660ElvrH6wGX/4FbNvq41qb/2vHezPt6UUjga7sixem 4zhSqlcoffSaFVg+c+E7OUGFfjgreK9rm3FND+qhH467hbaAeS7X5EKAK0/ncDxdsWMd y6q9UWb2Uss4QatmtQ+CxCZAZHRtkjGxIim2sOgS35h6hJbi27bz5uB8I1S9QIBSBDtl hMWPsMvTN27kd7TbZgPK44HBxVAuX55jpvi47b51v/DE82gaGGT2cWy7Nwk6Y65UuauL DwOQ== 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:content-transfer-encoding; bh=5JcPzuv+KudXcN4V7g/TzHoOBmzTOzWz3LCKTQiHoWQ=; b=svS9xhM3rQdkJ9unejDhnoQGmNi4PsEJyBCdcRR2h6W6/gsugJPYdg12a3yq0U46Zg DcaUo9DOA2lz60EIgSx/24pBvNGqPYhDpNM5G1/n7+sLANRpXQvOf1v2OWVysBdKX0fK ULusLtxbaEtt7MQSb4pWd7ZNpk3ip5UUxcUnymAXCHbK0B6t5oKMfll3nPEJApI4tgJp c/Zf82dzq33556ueKQM6F159I7ZwVknab6KCQLhqAFa2ZzDMsO/8byNDf6bL2YgqRYh2 3jBTBNLfIQfhE3s7GBhDw/vaTnxGaoyfKuRqikok9wTS6zisXauCzKnyv4oN7NaAUMxr DWFQ== X-Gm-Message-State: APjAAAU+dvNdguF3uhzjpQI6yrBqE1SPIa/JVT6afmN+HzB4BT1LEYnh D6ysiFC3RFXRNva9Tm6pi2MkJRCWvCacyJV7G7S7h7w= X-Google-Smtp-Source: APXvYqyx3a8TevAK1qWeQ/57dw3pCrq8lr/P0Sn3bRr7WQ6L03KFuv0wDNR8vCDubQMSw6OFtMIiy9Bm3aeCu9iCZ8U= X-Received: by 2002:a67:ee98:: with SMTP id n24mr4055381vsp.92.1566342529150; Tue, 20 Aug 2019 16:08:49 -0700 (PDT) MIME-Version: 1.0 References: <20190803030532.1D33375D900@ary.qy> <0CB7D475-6DDE-403D-BA65-E38C89A6D90A@kitterman.com> In-Reply-To: From: Brandon Long Date: Tue, 20 Aug 2019 16:08:37 -0700 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: "Murray S. Kucherawy" , Scott Kitterman , IETF DMARC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] New proposed wording for p=quarantiine 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, 20 Aug 2019 23:08:53 -0000 On Sat, Aug 10, 2019 at 1:44 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: > > Hello, > > to the idea to amend the existing definition of p=3D: > > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check be treated by Mail Receivers as > suspicious. Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > > the text =E2=80=9C > > The Domain Owner wishes in addition, that the sender of messages failing = DMARC are notified about the suspicious > handling with an appropriate rejection message. Senders not willing to b= e notified that their message is suspicious, > shall use the NOTIFY=3DNEVER service extension. > > In the past, Domain Owner could express as wish either to reject or to qu= arantine. Considering that from the options: > only reject; only qurantine; and quarantine, while notifying the sender a= bout the suspicious handling of the message; > nobody will choose only to quarantine, the interpretation of what the Dom= ain Owner wishes by publishing quarantine was > changed to include the rejection component.=E2=80=9D > > so far two voices were against. The reasoning against the amendment is t= hat writing what the domain owner wants is just > its preference, not anything binding, and the current definition is suffi= cient. > > My motivation in favour the amendment is, that currently nobody has the p= ractice to quarantine messages and inform the > sender of the special delivery status at the same time. Spelling more p= recisely what the domain owner wants will > suggest the implementations to implement precisely that preference. It's not standard, but Google does add a string DMARC:QUARANTINE to our 250 response to DATA for messages that policy evaluated to quarantine. I'm not sure anyone ever noticed, of course. We've been doing it since 2012. I'm not agreeing with the amendment, merely pointing this out. Sender notifications would have to be one of: 1) Something like Google does, some 2xx response that contains extra information the sending server would have to act on (which becomes challenging in forwarding situations) 2) A 5xx response but also accept the message so a DSN is generated by the sending (maybe intermediary) server. While I'm sure plenty of servers already do something like this at least for honeypots, this seems like a twisting of the standards. 3) A 2xx response, accept the message, and the receiver generating a DSN. This has the obvious typical backscatter issue. So, I can see why our implementor chose #1, but also the low utility of it. Brandon > > With other words, the sole reason why a receiving host does not notify th= e sender for quarintined message might be, that > the receiving site has not come to this idea. The additional text remove= s the cause. > > If there was a common practice by now to deliver as junk and reject with = appropriate text at SMTP level, then the > amendment would have been less necessary. > > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > > > > > > On Wed, 2019-08-07 at 08:13 -0700, Murray S. Kucherawy wrote: > > On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman = wrote: > > > Policy is an indication of sender preference, not a directive the rec= eiver must follow. I think the definition is fine. If the sender prefers = failing messages be quarantined, then they should use that policy. They wo= n't get what they want in all cases and that's fine. > > > > This matches my understanding. > > > > -MSK > > _______________________________________________ > > 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 Aug 23 09:09:34 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 3567D120020 for ; Fri, 23 Aug 2019 09:09:32 -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 gCYhulbSbO5w for ; Fri, 23 Aug 2019 09:09:30 -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 143BA120108 for ; Fri, 23 Aug 2019 09:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1566576567; bh=YtSB6ES7KI1gmHZtLJ5WehY3pGLazkV9sPw4dsKY8DQ=; l=928; h=To:References:From:Date:In-Reply-To; b=DjDhTiVhdAjFwdXmJBDRXTUKqmqyx5xAC1AkwOrsd8OP1aMQTKeXCl7cJyZNm9uEz GqPPddZ1O802havtYSQqkgODfdhR1ql3JsS/zXP6wygnwpPjTqSUqZ71OVWAwNFhlJ 1GWxpvIfzAkyMTtOONweVnz03TzAWcr/YftwTqX4gV+nnPL4SjwLCn6Ajisyb Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC082.000000005D600FB7.000051CB; Fri, 23 Aug 2019 18:09:27 +0200 To: dmarc@ietf.org References: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> <014c01d547b6$85c30c30$91492490$@leemankuiper.nl> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Fri, 23 Aug 2019 18:09:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <014c01d547b6$85c30c30$91492490$@leemankuiper.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies 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, 23 Aug 2019 16:09:32 -0000 Hi all, I made some more adjustments, including the addition of a 1-record example report. By properly setting the attributes of the feedback element, the version can be parsed by generic xml tools and doesn't need to be written as an element. I bumped the version to "http://dmarc.org/dmarc-xml/0.2". I think we all agree that some changes are necessary. Best Ale On Wed 31/Jul/2019 17:42:12 +0200 Freddie Leeman wrote: > Thanks Kurt, I’ve made the adjustments to the document. > [...] > > Van: Kurt Andersen (b) [mailto:kboth@drkurt.com] > Verzonden: woensdag 31 juli 2019 17:00 > [...] > > Speaking from experience, it can be helpful to be able to do in-place comments/markup so I've posted http://bit.ly/dmarc-rpt-schema - please make any adjustments in "Suggest" mode or comments you feel appropriate. The invitation extends to all members of this group. > > > > --Kurt Andersen -- From nobody Mon Aug 26 21:17: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 DD5C1120973 for ; Mon, 26 Aug 2019 21:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=marcbradshaw.net header.b=js6GXQX5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kdVD8B0j 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 SlWOGGX_i0jL for ; Mon, 26 Aug 2019 21:17:18 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDF01200CE for ; Mon, 26 Aug 2019 21:17:18 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id ABA42682 for ; Tue, 27 Aug 2019 00:17:17 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute2.internal (MEProxy); Tue, 27 Aug 2019 00:17:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=/FDzzXE ASpPpIAZyGc6zZ03IiCfDdccizuiZ0KaTJcI=; b=js6GXQX5kXbtdsJLTMqbQdE L+AZcNxOdNPJsTH5QZBzbpRg9hX72pzC+oXse7TU7Dbxr7ygZ001QZmvvhRJGs3a NJXLs47VXwHW2RGtqJOVIw8bQzXYsbl7LVNIhuIrgzbCjR91jcuY//Z7qW3eiQCz PcrIgV35kW8eJfVnfQVsbtdVu8WzCKLb2U7DRK4XWraPLBy1u+2I7KZ1s6ha3xDM JywRBtr5CrpdxzdONN0nelg3xYJOdfyHhyPdZMxZYfnj+bM8lNlf+7T58E0wOCXJ 0IfyOSxT34tO5X8M0aFjlYVFZD9uLcDqJKpO9/FZaJq1jgJGb9mkcBpEkIa1Cug= = 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=/FDzzX EASpPpIAZyGc6zZ03IiCfDdccizuiZ0KaTJcI=; b=kdVD8B0jqtABkAJdBelfSs RtY0jyuZ0PBjGOYpSOokmLnxIFVbaAEdrKv0slQHe9fpc556QXlNgb0brFoBBY9Y IFFJTQZnQQmkLRsNtUz9HK8DIeUUcaihF9ETK/heWKM1yrDUNrsJJjvTZckV6P2G WFYLBN2UVgAG9N7dGPxr+AWa2YIEvzXfYGzRdnGxdwTbSTP0m/ONtA5wMPYXtWQQ 3myXhWp99tfqE/9IE2n86NJaVlhoexE1hV7xC7Q93yrUoKrywOsLfxo8RVcVjSLW wIVBmEbkAZWrglznDX/QMHeYeJXqsAuAXl8rvWC4Tq7REwmvpDbGHTK/jbE//qEw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehhedgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhepofgfggfkjghffffhvffu tgesrgdtreerreerjeenucfhrhhomhepfdforghrtgcuuehrrggushhhrgiffdcuoehmrg hrtgesmhgrrhgtsghrrggushhhrgifrdhnvghtqeenucffohhmrghinhepsghithdrlhih pdhtfihithhtvghrrdgtohhmpdgumhgrrhgtrdhorhhgpdhivghtfhdrohhrghdpmhgrrh gtsghrrggushhhrgifrdhnvghtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrtges mhgrrhgtsghrrggushhhrgifrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B90414C000A6; Tue, 27 Aug 2019 00:17:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-139-g73fcb67-fmstable-20190826v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> <014c01d547b6$85c30c30$91492490$@leemankuiper.nl> Date: Tue, 27 Aug 2019 14:16:56 +1000 From: "Marc Bradshaw" To: "DMARC IETF" Content-Type: multipart/alternative; boundary=f3361a6f86704582a6b0f13819f701eb Archived-At: Subject: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies 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, 27 Aug 2019 04:17:20 -0000 --f3361a6f86704582a6b0f13819f701eb Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable These changes make sense to me. On Sat, 24 Aug 2019, at 2:09 AM, Alessandro Vesely wrote: > Hi all, >=20 > I made some more adjustments, including the addition of a 1-record exa= mple > report. By properly setting the attributes of the feedback element, th= e > version can be parsed by generic xml tools and doesn't need to be writ= ten as an > element. >=20 > I bumped the version to "http://dmarc.org/dmarc-xml/0.2". I think we a= ll agree > that some changes are necessary. >=20 >=20 > Best > Ale >=20 >=20 >=20 > On Wed 31/Jul/2019 17:42:12 +0200 Freddie Leeman wrote: > > Thanks Kurt, I=E2=80=99ve made the adjustments to the document. > > [...] > >=20 > > Van: Kurt Andersen (b) [mailto:kboth@drkurt.com]=20 > > Verzonden: woensdag 31 juli 2019 17:00 > > [...] > >=20 > > Speaking from experience, it can be helpful to be able to do in-plac= e comments/markup so I've posted http://bit.ly/dmarc-rpt-schema - please= make any adjustments in "Suggest" mode or comments you feel appropriate= . The invitation extends to all members of this group.=20 > >=20 > >=20 > >=20 > > --Kurt Andersen=20 >=20 > --=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 -- Marc Bradshaw marcbradshaw.net | @marcbradshaw --f3361a6f86704582a6b0f13819f701eb Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
These changes m= ake sense to me.

On Sat, 24 Aug 2019, at 2:= 09 AM, Alessandro Vesely wrote:
Hi all,

I made some more adjustme= nts, including the addition of a 1-record example
report.&= nbsp; By properly setting the attributes of the feedback element, the
version can be parsed by generic xml tools and doesn't need = to be written as an
element.

= I bumped the version to "http://dmarc.org/dmarc-xml/0.2".  I think = we all agree
that some changes are necessary.


Best
Ale


On Wed 31/Jul/2019 17:42:12 +0= 200 Freddie Leeman wrote:
> Thanks Kurt, I=E2=80=99ve m= ade the adjustments to the document.
> [...]
<= div>> 
> Van: Kurt Andersen (b) [mailto:kboth@d= rkurt.com] 
> Verzonden: woensdag 31 juli 2019 17:= 00
> [...]
> 
> = Speaking from experience, it can be helpful to be able to do in-place co= mments/markup so I've posted http://bit.ly/dmarc-rpt-schema - please mak= e any adjustments in "Suggest" mode or comments you feel appropriate. Th= e invitation extends to all members of this group. 
&= gt; 
>  
> 
> --Kurt Andersen 

-- =






_______________________________________= ________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
<= br>

--

  Marc Bradshaw
  marcbradshaw.net = | @marcbradshaw
--f3361a6f86704582a6b0f13819f701eb--