Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 02 December 2020 00:16 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
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 BCFD53A0BE7 for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 16:16:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 (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 fKNkDk97V9pX for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 16:16:21 -0800 (PST)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 9CCDA3A0BE3 for <dmarc@ietf.org>; Tue, 1 Dec 2020 16:16:21 -0800 (PST)
Received: by mail-vs1-xe2a.google.com with SMTP id q10so720985vsr.13 for <dmarc@ietf.org>; Tue, 01 Dec 2020 16:16:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GKsZkpWBk5vNM+kpw1lTeH9oQtOEjyACYd5MMjatgM4=; b=fHHrrMUw8pIUrVAZXzEuXp91R+xWx70jWH46tOCA4IHlD88MSrgzpIV3dnWpTqQ0S2 ESFMV21ALPs5+/6gLVuw+dc61bnhhbGX13SZ0PFtNmpk2AfoO6X+Cs5fl8TpnAtn481k QaKqz4HTdurUkxt6RlzB+29suxaVFn6oC66myFIvH9jeIeAjNSIzy48E+71L48Xx3z3p KaFWDwR4k/2qZy8fc7vhiqTBqctg8EN75blC75564czLWlZ+4+YG0ZlNzCsShbHrEmPP ymI7VSdKobg/LPhLXm7xD4bnm68VoLi2DNCSOvqaNqHn/QZD5yLGC3MOQ+IpxAZ6Xyzf yO9g==
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=GKsZkpWBk5vNM+kpw1lTeH9oQtOEjyACYd5MMjatgM4=; b=sygJ4wwmXt8Lpf66/B5ZJmUzna7siuxQfebKYkYIrYHuAC2CJ8eWDofmstkbBE6YPG 2YNEs63YGdcfwWqk4miO9ydD8l4fE/zKdW23hoz0UcmhgeV3Zdiwp0GNUrq+pPRAxU6r foMgNdxdHNZUdCy6H5W3bsvH5Zdc34kHcTA5d20Bjo4BmYKL64hM3w5PAKnSwTsqoacE 8Ed2QLE7jRsWKv4Hfv5x/LCVpnxkbUBxKbAUVyCe6BC0qtl00ZeUtyPf2rZcIV9IMG+2 cj9EC9Dn98sVkYSHGqzUCaQadCqxNThyJufxAxqrKwKp+po80g1ND9bmxT4q8kL8zljd /7Cg==
X-Gm-Message-State: AOAM531WyPxbuNAmuxCiv6JqjovzxpF/HpGKvAuaL3RF6PRcOSC/ctzP AAbe8z2J/Hv+3zFQ477a5HzBA+fblAzef2ZYN3W7u9+g
X-Google-Smtp-Source: ABdhPJztjymaTjnrIFykwsLliqPW4Esx5PBTljXdrpLDwY7AdgJOIDGMAjG3c0qYkmG799Z3vP0PDaEHAL18XuXX8U0=
X-Received: by 2002:a67:2084:: with SMTP id g126mr5548729vsg.42.1606868180517; Tue, 01 Dec 2020 16:16:20 -0800 (PST)
MIME-Version: 1.0
References: <a49a7a79-6c52-ded7-60a3-754cd12fb7c3@taugh.com> <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com>
In-Reply-To: <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 1 Dec 2020 19:16:09 -0500
Message-ID: <CAH48Zfx448mxL9Btmqp0xUCK88yN9=h6Qus-4u4J2_W14aXwUw@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000019c5ea05b570272b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/wI7syg8SlG5KZMoe-UHFffHX18Y>
Subject: Re: [dmarc-ietf] Ticket #39 - remove p=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: Wed, 02 Dec 2020 00:16:26 -0000

I have always assumed that p=quarantine and pct<>100 were included to
provide political cover for "Nervous Nellies" who were afraid to enable
p=reject.

As an example, suppose Nellie makes the decision enable p=quarantine and
then goes badly:

If the recipient reports reject instead of quarantine, she can say:   "They
were not supposed to review it!  They did not follow instructions!"

If the recipient reports quarantine as requested, she can say:   "They
agreed to look at it.   We can assume that they will release it to the user
after seeing that the message is innocuous, but the quarantine disposition
decision is not shown in the DMARC reports."

--

As an email gateway administrator, what I reject and what I quarantine will
be determined by my confidence level in my system's risk assessment.
 Sender request will have nothing to do with it.

Pct<>100 is pretty much similar.   A sender can specify pct=20, but that
does not mean that I am going to allow spam into my system 80% of the time
simply to make the sender happy.   Nonetheless, p=quarantine and pct=20
might allow some organizations to move away from p=none, thinking that they
are taking "baby steps", and that is a good thing.

Disabling a deployed feature is a big deal.   Leaving it deployed is a
useful ruse to promote deployment.   I favor leaving both mechanisms in
place.

Doug Foster




On Tue, Dec 1, 2020 at 6:56 PM Dave Crocker <dcrocker@gmail.com> wrote:

> On 12/1/2020 3:17 PM, John R Levine wrote:
> > #39 proposes that we remove p=quarantine.  I propose we leave it in,
> > even if it
> > is not very useful, because trying to remove it would be too confusing.
>
>
> If it is confusing to remove it, it is probably confusing to keep it,
> albeit a different confusion.
>
> Since protocol specifications need to be precise in their semantics, so
> they are understood the same way by both producers and consumers, I
> suspect the issue, here, is a failure to adequately specify the meaning
> or a failure to specify something that is mutually useful and desired.
>
> So rather that be administratively expeditious for the working group
> process, I suggest this issue gets some meaningful discussion.  My email
> archive indicates it hasn't gotten any discussion at all.
>
> Just waving this through because it will be a hassle to deal with it
> invites random differences in its use, and that is death to
> interoperability.
>
>
> d/
>
> --
> Dave Crocker
> dcrocker@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crocker2@redcross.org
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>