Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Дилян Палаузов <dilyan.palauzov@aegee.org> Sun, 28 July 2019 12:48 UTC
Return-Path: <dilyan.palauzov@aegee.org>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6EC12010C for <dmarc@ietfa.amsl.com>; Sun, 28 Jul 2019 05:48: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, 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 dQJnjRp3pSg6 for <dmarc@ietfa.amsl.com>; Sun, 28 Jul 2019 05:48:14 -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 EAAE8120144 for <dmarc@ietf.org>; Sun, 28 Jul 2019 05:48:13 -0700 (PDT)
Authentication-Results: mail.aegee.org/x6SClwEP027080; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564318083; i=dkim+MSA-tls@aegee.org; r=y; bh=mKE2GMWtMdRORCfU0qE6Gp7q+55qPB1ZBS484+kLjSY=; h=Subject:From:To:In-Reply-To:References:Date; b=AnDXErbv4twax20PozIAxiJo0MDpVjiXTEOytFeqvhkrcVLaLlY1Xk9TpfiwS7M7O sOiFXvt74Fr0oeAvfTsdyrW+qjMiqrZaBjcmIp4Btpz1iJMrGl5ZQKkQdgSFK9l4uO uRHsADSRsJS5hIT8k4JuvxBrz80Tdu50tsm+6WjEU2On6d3oG87jHbie6WV9S4AKA8 EbkLN7N1ibeJQJJynbChoVxhJIK4pTBRDh5YCZRRxlMNJrrBxSfOCMNlPhe/vNBb3h 8p3UOMhVPP9n+M+/9a/GADOzO1sTJBVLzpwE/qnLZmK2DtofTMOKZii1wZudlWFC1o r3XuDhUYRUdSjgdSVRLN7ectdcyA6/18bA6JLMw6UUc264R+D6bK6sh3ezg8gBfp3y kAd9Vfyqt4lwSm9WNHDM6rGXF/lGsTILpEmW1ZVz0rX/Yq57qDhDSkr1ufI12bEoaT kOY/5kxsn0NerG6BgB/N0P51WXrt7xE/D/oBoNz8u+JXOA+ft7+MQoXCHTE1h3qrw8 h84xSrupChLeS219XPg5rUDcKEMlU3LmrGJ0JMbsyeHYzcWwmpFAptrQ4zUzVOuAVg o6kOjsok5SlqYeVx4NreQ9ZMAYqndCiDgk/5CUglkuOBKf1Yj46y60jW/9mYGLhWG9 lrFKmmcmEo8FRsyQP7g8AIxw=
Authentication-Results: mail.aegee.org/x6SClwEP027080; dkim=none
Received: from Tylan ([88.203.199.243]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6SClwEP027080 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Jul 2019 12:47:59 GMT
Message-ID: <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: Alessandro Vesely <vesely@tana.it>, dmarc@ietf.org
In-Reply-To: <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it>
References: <a8ac130a671f5bcd1bf9f09781325e84a9f1fda6.camel@aegee.org> <b903c983-5c65-5b17-62bf-9ff42ffdbaaa@corp.mail.ru> <CAJ4XoYeJRcGfO7LntM6LBeJ5rMOcb0D=ya31Rm8utoWTqE7oXQ@mail.gmail.com> <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <CAL0qLwYYEMofia2S4a8oXsf02fnJg7y+DovvMWZENUW+4yUyiw@mail.gmail.com> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <CAL0qLwbX4T5=EFZtwPPk9aYdUpR72c4r5t8SB1WETkpXEtUahQ@mail.gmail.com> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <CAL0qLwbixESJypwDG3NMuv22+Lb3w-iHPok8xZf-hy3Fiu38EA@mail.gmail.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 28 Jul 2019 10:49:12 +0000
MIME-Version: 1.0
User-Agent: Evolution 3.33.90
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/YoVdc-xufsLUoBpdQJ9NHpyiBa8>
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\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2019 12:48:16 -0000
Hello Alessandro, abolishing policy quarantine means with p=reject that for failed messages there should be some penalty and the receiving site decides on the form of the penalty, e.g. quarantine or reject. In fact I see the DMARC specification updated to use consistently some neutral word, like penalty or punishment attached to p=reject, once p=quarantine is abolished. This word is then dissected into “quarantine or reject” at the place where it elaborates on the possible penalties, or how to do reject right. The penalty could be implemented with reply 550 Message failed DMARC validation and was delivered in the Junk folder of the recipient This form has the advantage over either quarantine or reject, that for lost messages, the sender can call the recipient and the recipient can dig for the message. So the message does not have to be resent and no surprizes happen. I do not see how could this reply mess anything, except in the cases where the sender does not speak English. > OTOH, quarantine lets one forget about delivery, perhaps with a backhanded > thought of recipients rummaging through their spam folders in search of a > missing message. That style seems to me to better suit ESPs, whose duty is > rather to have a lot of mails sent than to make sure that each message is > acknowledged, albeit they try and maximize the ratio. > > IMHO, by abolishing quarantine, we make the protocol less flexible than it is. If an ESP wants to forget about delivery, the ESP likely does not care whether it has implemented DMARC correctly and then it does not need quarantine mode. The penalty is applied to messages that are either sent by spammers or by the domain owner. If messages are from spammers, for the domain owner it is irrelevant, what kind of penalty is applied, but for users doing reject means having to scan less messages in the Junk mailbox. If messages are from the domain owner and fail DKIM/DMARC validation, the only way to fix DKIM/DMARC is to use policy reject. There is no other way to find out which messages fail DKIM/DMARC, as single message faiulure reports are rarely sent, and without knowing which messages fail DMARC fixing the problem is unnecessary complicated. So here, p=quarantine is in fact an option for providers, who do not care, whether they have implemented DMARC correctly. All that said: • Is there a consensus on abolishing policy quarantine? • If policy quarantine will be kept, will the none>quarantine>reject order be abolished, meaning “quarantine” will not be handled as softer variant of “reject”? Meaning with p=reject; pct=30 messages are either delivered or rejected, but the specification does state anything about quaratining 70% of the failed messages. The first argument in favour of keeping policy quarantine was exactly this order (quarantine is a softer variant of reject and before deploying reject one has to exercise with quarantine). Regards Дилян On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote: > On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote: > > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy <superuser@gmail.com> wrote: > > > > > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins <steve@wordtothewise.com> wrote: > > > > It's interesting that the industry has decided to interpret "p=reject; pct=0" the way we intended "p=quarantine; pct=100". > > > > > > It's semi-explicitly defined that way in the RFC, isn't it? > > > > > > If so, we should fix it because (a) I don't think that's how we intended it, and (b) in any case, nothing in there should be only semi-explicit. > > > > rfc 7489 6.6.4 > > > > "If email is subject to the DMARC policy of "reject", the Mail > > Receiver SHOULD reject the message (see Section 10.3). If the email > > is not subject to the "reject" policy (due to the "pct" tag), the > > Mail Receiver SHOULD treat the email as though the "quarantine" > > policy applies. This behavior allows Domain Owners to experiment > > with progressively stronger policies without relaxing existing > > policy." > > > > It's pretty clear and well-defined; the case we're talking about, "p=reject; pct=0", is > > just a special case of this general rule. > > > > All emails will not be subject to the "reject" policy due to the pct=0 tag, so the mail > > receiver should treat all emails as though the policy "quarantine" applies (which > > is the same as "p=quarantine; pct=100"). > > I, for one, had missed that point. Thanks for clarifying it. > > It seems to mean that the resulting steps are, for example: > > > "p=quarantine; pct=0" (check From: rewriting) > "p=quarantine; pct=10" (some messages go to the spam folder) > "p=quarantine; pct=20" > .... > "p=quarantine; pct=100" > "p=reject; pct=0" (same as the previous step) > "p=reject; pct=10" (some messages bounce back) > "p=reject; pct=20" > .... > > > Is that what we want to suggest? In that case, we should be clearer. Perhaps > by adding an example in a new appendix. However, I hardly see the above > sequence as progressive. > > I had always considered quarantine and reject to be two more or less similar > alternatives. Each has its merits and shortcomings, and can be chosen > according to a sender's needs. > > An advantage of reject is that one gets NDNs, which are much more universally > adopted than failure reports. Perhaps a bank or similar transactional sender > would rather prefer reject, because they can timely resend bounced transactions > or notices thereof in order to have their duties accomplished. > > OTOH, quarantine lets one forget about delivery, perhaps with a backhanded > thought of recipients rummaging through their spam folders in search of a > missing message. That style seems to me to better suit ESPs, whose duty is > rather to have a lot of mails sent than to make sure that each message is > acknowledged, albeit they try and maximize the ratio. > > IMHO, by abolishing quarantine, we make the protocol less flexible than it is. > > > Best > Ale
- [dmarc-ietf] Abolishing DMARC policy quarantine Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Ken O'Driscoll
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Laura Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Tim Wicinski
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Brandon Long