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