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

Brandon Long <blong@google.com> Thu, 10 December 2020 00:05 UTC

Return-Path: <blong@google.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 31DF93A07B3 for <dmarc@ietfa.amsl.com>; Wed, 9 Dec 2020 16:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 3G-DgZzNN7LL for <dmarc@ietfa.amsl.com>; Wed, 9 Dec 2020 16:05:05 -0800 (PST)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 54EC43A07A0 for <dmarc@ietf.org>; Wed, 9 Dec 2020 16:05:05 -0800 (PST)
Received: by mail-ua1-x936.google.com with SMTP id t15so1120729ual.6 for <dmarc@ietf.org>; Wed, 09 Dec 2020 16:05:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AewpJCkC3H2R+Kwif4uJ4i+Om5HJ5dQxSnwampSM0zY=; b=Y4U26G4ZPA7VapnWYPGHj8phMeorvNdN+hT1FJbET310DFlO5/bOMHYjFUCOHxpPGv vERcUMGtytPdSlS109kfU6thYw7XYiK8g3g/67epH4nBAU51Ei5Yg7HV6A1OhkAPHPBd uHLhLycTjwPes1joNNscu2PZfrgclxOKl8ysse+ee1fSSL6C/1fRhoWTZycR+85r3wRi huluq8XPsPAUarPoApw45vXaXMQijyeqeDqyp7Xr67QiwVGlNmvbJzQVGfohWuWdOMqa kYL5ULzOnNSQOkwlpYXnctOAq3TIfXr4NAxum15AvAKzZdke4Sqh/6O7hRxgWWoQO85p KCOA==
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=AewpJCkC3H2R+Kwif4uJ4i+Om5HJ5dQxSnwampSM0zY=; b=TgZRx6GXRJIvz+C69JP7VfeX/vGwr2f8nP6r3m5HEOMlYD77oYL01XVyVK2IjyjY5g cDix2sghClclf8yKVXSXAOjFzBlpGaX/zgGmDI3GsMwQ4mr5um07IOIoROjw62w6GKbe DBwpcMKDUDP4X0uTEm+ZeBOuqTX08pZEAOTTA8Im07EnHgssFSdfSzdtq0QH/x874Mlv 1Ua1ZCWXxwDMitTePkM6FO2dZjFcZqfXctFXFT5yfvRwx89Rthklc+xvLiKukZKJKLuh nhldANraTtUBctzpUKlBm1DIBuqlv6GMXVgfYKrLslr62eGXbZ6nch0OPKFstg2hKa4T SQ4w==
X-Gm-Message-State: AOAM532o0Ziz6hUUzVsDKSZq3aFQMnTkxnRI/60TcAUoQKT04bbMkfdQ Q4VxBoHT01FR/6fgR9LL4VH7t4zUfQL3SUUorPel8l8Jzg==
X-Google-Smtp-Source: ABdhPJzJ3WsnFihB/mgTBgx05T07Cq97s/Hc6v3GZWfZFbh/ex3hmSOYNSiAAudtwD2+u0I/t99CBlQn/LFNZ2pdANY=
X-Received: by 2002:ab0:55da:: with SMTP id w26mr4668819uaa.31.1607558704079; Wed, 09 Dec 2020 16:05:04 -0800 (PST)
MIME-Version: 1.0
References: <a49a7a79-6c52-ded7-60a3-754cd12fb7c3@taugh.com> <5C559553-3F45-494D-9714-F7BC47BB82FF@wordtothewise.com> <B3AD64BB-1636-4632-ABB5-96E675CDC5F1@bluepopcorn.net> <2F1BED43-5AE5-42BC-AA45-67C5FDAF6CB8@wordtothewise.com> <CAHej_8=qwDDYA3i9tb_t-EjtJXabq1X_pstRpuAp_wwgFUcHDA@mail.gmail.com>
In-Reply-To: <CAHej_8=qwDDYA3i9tb_t-EjtJXabq1X_pstRpuAp_wwgFUcHDA@mail.gmail.com>
From: Brandon Long <blong@google.com>
Date: Wed, 9 Dec 2020 16:04:51 -0800
Message-ID: <CABa8R6s9ib5oh2OtRLhVSm4TN52ciCHM19f+LKvgnaWxBx1miw@mail.gmail.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000083856805b610eda3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/jBkhUC7aUM8dY2hG9kZvfLa5ohc>
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: Thu, 10 Dec 2020 00:05:08 -0000

On Thu, Dec 3, 2020 at 6:22 AM Todd Herr <todd.herr=
40valimail.com@dmarc.ietf.org> wrote:

> On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins <laura@wordtothewise.com>
> wrote:
>
>>
>>
>> On 3 Dec 2020, at 06:03, Jim Fenton <fenton@bluepopcorn.net> wrote:
>>
>> On 2 Dec 2020, at 1:47, Laura Atkins wrote:
>>
>> p=quarantine is quite useful, particularly for those folks who are trying
>> to get to a p=reject state.
>>
>> In practice, senders who publish p=none don’t find all of the indirect
>> mail flows as some mailing lists do nothing to transform the 5322.from
>> address for a p=none policy. Senders have found that when they switch from
>> p=none to p=quarantine pct=0 they regularly find mail that was not failing
>> for a p=none.
>>
>>
>> I’m really confused by this. It sounds like the 5322.from address
>> rewriting is creating additional errors that didn’t exist beforehand, and
>> that’s the opposite of the intended purpose. Isn’t the purpose of rewriting
>> the 5322.from address to change the domain to that of the mediator, which
>> should redirect reporting to the mediator rather than the original sender?
>>
>>
>> What I am trying to say is that as I understand it from the folks who
>> professionally deploy DMARC, they regularly use p=quarantine pct=0 as part
>> of the deployment process. There are DMARC failures that go undetected in a
>> p=none situation but that is detected in a p=quarantine  pct=0 situation.
>> My understanding was this was related to indirect flows through mailing
>> lists and how mailing lists are handling the header transformation but it’s
>> possible I got that piece incorrect.
>>
>>
> Time was (and may still be) that there was a very specific type of mailing
> list for which p=quarantine, pct=0 was required to get accurate DMARC
> reporting, and that was for mail that transited Google groups. There've
> been a couple of public discussions of the topic over on mailop, including
> a thread from April 2018 with the subject of "DMARC p=quarantine pct=0".
>

Right, to be clear what is going on:
Google Groups only does 5322.From rewriting if the domain is p=quarantine
or p=reject, it ignores the value of pct because it can't know whether the
receiver will apply pct or not to that specific message.

It doesn't apply 5322.From rewriting to p=none domains so as to reduce the
amount of rewriting it does.

Because we don't do the rewriting at p=none, the dmarc reports that people
get at p=none will show the messages transiting groups failing dmarc.

When you switch to p=quarantine pct=0, no one should apply quarantine (so
it's equivalent to p=none), but Groups will start rewriting, thereby
removing all of those failures from your reports.  Yes, you won't see those
messages in the reports at all anymore because they are no longer using
your domain.

This isn't ideal, it means reports at p=none for many domains are very
noisy and so harder to use to find what needs to be fixed before going to
p=quarantine.  There's a trade-off between how best to support domains who
are in p=none and making it easier for domains to progress to p=quarantine
and p=reject.

Even without this quirk for Groups, I wouldn't remove pct.  I think
controlled rollouts and not knife-edge changes is good practice.

I see this thread is actually for removing p=quarantine, I'm voting against
removing it.  Even if we think that domains that use DMARC should all
progress to p=reject (or even that most domains should), progressive
changes and rollouts make these things possible, and p=quarantine is a
safer step than p=reject.

There is potentially an argument from the other threads where a domain
owner could instead assign a level to a domain indicating how badly they
think that abuse of the 5322.From of this domain is, and then the RFC could
indicate that receivers SHOULD/MAY treat failures at different threat
levels by rejecting or quarantining messages.  That would definitely lead
to a level of indirection in the progression of changes, since a domain's
threat level doesn't normally change... but adding yet another tag for say
confidence or rollout level on top of pct starts to really seem like
overkill.

lvl=high confidence=medium pct=0

(My mail should be protected, I'm only part way through ensuring that it
is, and this level of confidence is at 0% rollout which is equal to 100% at
the lower level)

Brandon