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

Seth Blank <seth@valimail.com> Wed, 02 December 2020 02:06 UTC

Return-Path: <seth@valimail.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 F1FC63A0E8C for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 18:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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=valimail.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 zq-etIzByg9K for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 18:06:25 -0800 (PST)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 61E713A0E8B for <dmarc@ietf.org>; Tue, 1 Dec 2020 18:06:25 -0800 (PST)
Received: by mail-ua1-x92b.google.com with SMTP id r23so28993uak.0 for <dmarc@ietf.org>; Tue, 01 Dec 2020 18:06:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y+uQ1X5B6CLT5DCQgBovoJSP2WVmUf6rfYQLQgbcFaY=; b=VCQMPni1HpGlM+9Lx5HrPjQAkuVuvHmVea8JEGqZadtaTn4CPjlt+28oeE2llYxwKx /nZ66s0xwXmaKus79q2eRba9+eMGN3yILhrUbT+CH8SEfNoAckC3TK+u7gpso9bWChrw kQ0CklhAFYsiGI9Cr3zZLOR+yY/eD5mNu/GMFf3Pa3puC0BZ/r+3PMNzeQ8pH4YFAW26 oMWUmp16xqfUoZDNfxjj2ox+gdnbLqEW0WTn3BzcMMlTDtUgDIyDJrBDOJc7kwBNpsY5 pmxkpvm+hHwmimVa9VQMTSUUPn6gt26PwR/dvhCwe5XuLz46qMRMsjwthN8yFmF4wFxV 6rOw==
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=Y+uQ1X5B6CLT5DCQgBovoJSP2WVmUf6rfYQLQgbcFaY=; b=YgEp3dra//zQi+whNlLXq4HKHdESZ5mI0xmqCZjPYtbakAqtKqHs0gfv7FFi0LDgrm r3chi5z3Xj/LlmbCTOxo3c1F8Q9RYbLMX3pchzWxDLZ8SDpYwvwfbfe8CXhnMv9/+PhL kYbP9b070jzGvT4KZFKnZQw8TVB1soTEa6engfWMh+ignJXZtmK6R4FWT6b3R3yV7f5N Av5G0jYZgLvtpSsKj9bKuzItHS55j9gbkSotqIzQnRT8S4Yyf9qNNQvBKhopmMvFv2DD HwelCkYTObMEnXwwspEDQY5ImQ3ygJWD+72kv9u93S4hGNWZkalzHj8Su/Ukst1b6Q4K SIGA==
X-Gm-Message-State: AOAM530OzDF046h1KoCMyRX92kbv5G3OUelelFhb4OxELN68nEYYldBa Lubvl5l68Ox7fWyPX2XNRLBMv0ziWhm19+kNVp3ynQ==
X-Google-Smtp-Source: ABdhPJxi7Pc9dvcBA4Qp4kOtXuTx8XaZUpsLKneNP+O2pwkSTjpdg2YkmgJ3ift5hqpMEkqldN3jH/9ihbbT2TypqRk=
X-Received: by 2002:ab0:6285:: with SMTP id z5mr485839uao.0.1606874784208; Tue, 01 Dec 2020 18:06:24 -0800 (PST)
MIME-Version: 1.0
References: <a49a7a79-6c52-ded7-60a3-754cd12fb7c3@taugh.com> <2fc01257-3307-c453-18a0-bc423dccfe6a@gmail.com> <CAH48Zfx448mxL9Btmqp0xUCK88yN9=h6Qus-4u4J2_W14aXwUw@mail.gmail.com>
In-Reply-To: <CAH48Zfx448mxL9Btmqp0xUCK88yN9=h6Qus-4u4J2_W14aXwUw@mail.gmail.com>
From: Seth Blank <seth@valimail.com>
Date: Tue, 1 Dec 2020 18:06:13 -0800
Message-ID: <CAOZAAfPk=rpERs=wrhpWwc+co0yidTEwm0dpknH1m4kYs8GOMQ@mail.gmail.com>
To: Douglas Foster <dougfoster.emailstandards@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b62cfd05b571b07c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lGZ9Ws7Ex8tWe2U_3c8TDYXUHac>
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 02:06:28 -0000

Doug, please keep your arguments focused on the technical merits of the
matter, and do not make dismissive comments about users and their
motivations. Those you refer to as nervous nellies are the domain owners
who this protocol is designed for, many of whom are legitimately worried
about blocking good mail along with bad, especially in complicated
environments. We cannot dismiss a large class of users as being silly just
because their operational experience or business needs are different than
our own.

Seth, as Chair

On Tue, Dec 1, 2020 at 4:16 PM Douglas Foster <
dougfoster.emailstandards@gmail.com> wrote:

> 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
>>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* seth@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.