Re: [dmarc-ietf] Abolishing DMARC policy quarantine

Alessandro Vesely <vesely@tana.it> Fri, 26 July 2019 14:30 UTC

Return-Path: <vesely@tana.it>
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 904F61200CE for <dmarc@ietfa.amsl.com>; Fri, 26 Jul 2019 07:30:42 -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 vKtOztD2RPAn for <dmarc@ietfa.amsl.com>; Fri, 26 Jul 2019 07:30:40 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAA71200B9 for <dmarc@ietf.org>; Fri, 26 Jul 2019 07:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564151436; bh=CmOWQlCSHRtm8gEpHopdDkYX0inS2jMy9UDFBswjFw4=; l=2923; h=To:References:From:Date:In-Reply-To; b=DfSndzUC2TENubqweW3wEqsaAFZ6XFgvJV6teaCNpJdfiP5f+4yix5thRf7y5mNAW Eck7tNtlwQF6pXrPiv0YV2zYMOykz8PtBsQaBNaEG6Jn5M2feotA5bZ/dPohhF2JrS UzkQBFspWT60ZOGFcWjnSMNrt7Picfgiw+yLwgtn1e29eNjkUnxQ4k5YHBsnj
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 00000000005DC064.000000005D3B0E8C.0000679F; Fri, 26 Jul 2019 16:30:36 +0200
To: dmarc@ietf.org
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>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it>
Date: Fri, 26 Jul 2019 16:30: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: <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/qK3ZMvSQ-9e9apeprkRX_RS_Ivw>
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: Fri, 26 Jul 2019 14:30:43 -0000

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
--