Re: [dmarc-ietf] Priming the Pump for Discussion - Ratchets
Douglas Foster <dougfoster.emailstandards@gmail.com> Sun, 11 July 2021 19:32 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 8160E3A1AA3 for <dmarc@ietfa.amsl.com>; Sun, 11 Jul 2021 12:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=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 gDpiOkfwEZZg for <dmarc@ietfa.amsl.com>; Sun, 11 Jul 2021 12:32:30 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 C8E0F3A1AA0 for <dmarc@ietf.org>; Sun, 11 Jul 2021 12:32:30 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id x70so10374501oif.11 for <dmarc@ietf.org>; Sun, 11 Jul 2021 12:32:30 -0700 (PDT)
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=t+Ff5kyK9rvqSGMl48LEK/odKRZfJMJOZpGJ9HRF+2M=; b=rg2GicLk+SKPcW+TObme7CZTkaLLBAbmA9hE6P0jUtc2xyNHNVDiR/1aKSnZHheJew SdL4s3PMXCUgLYDsbioiElgtJF5jA1iOdKqkr5hO+kitMChs2SV5e+WHIxF0lZR2uxo1 k0x9j/UjKV2F7+oLbUczgcRyiq6KRkiy5/JTlAtRpXDcjD3MjfqtPplE30HnfOFztcG6 D+xWAy4YEj6VtAzBg5vOpdPZsJ2Aa0gGsQ1exzVLCP3dlWH1gODcRlVH16jQtDkaxmjT TJQzcCV75r4e0c+pKlWGQiDtWOb5KGD9UbO8PaluVGrmOer/UAAMYq2zoLzOlzJ2+y0z duVQ==
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=t+Ff5kyK9rvqSGMl48LEK/odKRZfJMJOZpGJ9HRF+2M=; b=LXTNaWvb3UHUamOud2gMtPjmsUjRDXQIBRLsUE7ZQfze7BDdj6OgouoZorzCkT9GxE Kaz/QKOlR6t7AK2McE2teoUxirzcIj7ASLziH/GBqNGbSBIAGlDfaoHbV4smQ8Ir0iIM 4mGrzpRwPr4VzhdUQmczBEWSpjvMgdsiRrvbsls8nFXyTbGYuyYDunVrA6iLCMHCZZhd ZWkb8baVGhxrXFzZ8ZSmaAYd8qhvzoKwJzUBN2qvz7w9n1DYGLSzZHqL1z5cOxSwSuAO G9Np5Che1CCwRIBTneiZ9tjI+7S1CYiMxtcjqOZLez2XFqjuKDuwttwpwPEfkdxfWQvb PYGg==
X-Gm-Message-State: AOAM5302mrwOaRJwr+Sp6ViNjDRt778SJ7YmvnshIv7rV5/nAkrcXZjn RO7jwOl7UDtL2HEoki2pFavwnd3XIao1n2bi3+5cDk8NPpc=
X-Google-Smtp-Source: ABdhPJzSX723qgX0juH2NBuojBVASbGzj+87MwjIKrlV3tq2dwoLtYrIb8oWlHL6Ka+3vdM3OqlSbiRwa8oW672WWp4=
X-Received: by 2002:a05:6808:1153:: with SMTP id u19mr7737520oiu.20.1626031949390; Sun, 11 Jul 2021 12:32:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAHej_8=yvgXP2WgHayhGU2Hg2E0RcNgZBFjfw1cM-qKWkTG-+w@mail.gmail.com>
In-Reply-To: <CAHej_8=yvgXP2WgHayhGU2Hg2E0RcNgZBFjfw1cM-qKWkTG-+w@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sun, 11 Jul 2021 15:32:18 -0400
Message-ID: <CAH48ZfzzVV90CkKX+mCKAfDvgzQY62csCO6Vp92Bh03_zL8jWA@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bca7c505c6de107f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/VjuEjsBBaBfNDA4IjqMvvtYLHQQ>
Subject: Re: [dmarc-ietf] Priming the Pump for Discussion - Ratchets
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, 11 Jul 2021 19:32:36 -0000
If we are willing to break upward compatibility, it might be preferable to define policy in terms of what the sender knows, rather than what the receiver should do. After collecting feedback, the sender should know whether all message sources are sending with SPF PASS, DKIM PASS, or both. This could be implemented with granularity based on the domain-part used in MAILFROM, and these four possible policy statements: Messages sent using organization domain for SMTP: · All messages with MAILFROM matching <FROM scope> will produce SPF PASS, at first hop. · All messages with MAILFROM matching <FROM scope> will produce DKIM PASS based on the FROM address, at first hop. Messages sent by mailing service providers using the service provider domain for SMTP: · All messages with MAILFROM not matching <FROM scope> will produce SPF PASS based on the SMTP address used, at first hop. · All messages with MAILFROM not matching <FROM scope> will produce DKIM PASS based on the FROM address, at first hop. We know that forwarding can affect DMARC and SPF evaluation, and that forwarding is outside the control of the sender. Consequently, when verification fails, it is the recipient system’s burden to determine whether forwarding has occurred, how the forwarding action affects the trust level of the message, and consequently whether the forwarding path is acceptable. One way to handle this would be for recipients of forwarded mail to register that fact with the system administrator, so that the system administrator could configure appropriate rules in the message evaluation system. Additionally, not all DMARC-violating impersonation is malicious, so even when impersonation is confirmed, it remains the recipient system’s burden to decide whether the impersonation should be tolerated or repudiated. Some implementations of sender authentication have used IETF specifications to simplistically implement message repudiation, without understanding the possible exceptions, and consequently without providing the necessary exception mechanisms. I am hoping that DMARCbis will include enough discussion of exceptions to reduce the likelihood of this error persisting forever. Changing the way we define policy might help achieve this goal. Doug Foster On Tue, Jul 6, 2021 at 8:46 AM Todd Herr <todd.herr= 40valimail.com@dmarc.ietf.org> wrote: > Greetings. > > The theoretical goal of any domain owner that publishes a DMARC record is > to transition from an initial policy of p=none to a final one of p=reject, > because it is only at p=reject that DMARC's intended purpose of preventing > same-domain spoofing can be fully realized. > > Many domain owners see the transition from p=none to p=reject as a black > box, in that they believe they have no way of knowing what the full impact > of such a change might have on their mail, and they fear irreparable harm > to their mail if they make a mistake. > > The designers of DMARC anticipated this fear, and built several different > transitional states, or ratchets, into the protocol, including: > > - The "pct" tag (https://trac.ietf.org/trac/dmarc/ticket/47) > - The "sp" tag (https://trac.ietf.org/trac/dmarc/ticket/48) > - "quarantine" as a value for "p=" ( > https://trac.ietf.org/trac/dmarc/ticket/39) > > All of these are designed to allow the domain owner to request that some, > but not all, of its mail be held to stricter authentication standards so > that the domain owner can dip a toe in the water before jumping in. > > The ratchets have introduced some problems, though: > > - The 'pct' tag doesn't exactly work like it's intended to, and really > can't because of the nature of mail flow, unless there is a high volume of > failed authentication for the domain in question. (There is a much longer > discussion of this in section 6.7.4, Message Sampling, of > draft-ietf-dmarc-dmarcbis-02.) > - Some domain owners have taken a "more is more" approach to ratchets, > figuring if one is good, all are better, resulting in needlessly > complicated policy records > > The purpose of this email is to get folks thinking about possibly > simplifying the ratchet mechanisms, perhaps boiling them down into one. > This thinking and on-list discussion on this topic would serve as a > precursor to further face-to-face discussion at the next interim working > group meeting. > > I'll start the discussion by taking an extreme position... > > Ratchet mechanisms don't help in any way that a short TTL on your DMARC > record won't help, and in fact you need the short TTL on your record > anyway, because if you're trying a ratchet mechanism and find it's too > much, you still gotta update DNS to roll it back. > > Getting to p=reject isn't a difficult undertaking, at least from a > technical standpoint. Enumerate all your mail streams, ensure that they're > authenticating properly, and boom, you're done. The proper tools for doing > that are p=none, a rua tag pointed at a mailbox that is parsed by automated > means, active daily monitoring of the data consumed in those aggregate > reports (so that mail streams can be enumerated and authentication problems > addressed), and time. Time is the big one here, because sufficient time > must elapse to ensure that all of your legitimate mail streams are > exercised and reported upon, and that can take many months in large > organizations or at companies that are in the business of seasonal email > sending. > > The big challenge to fixing authentication issues, especially in large > organizations, is usually in just finding who owns the host/process that's > generating that unauthenticated mail. That can add time to the process, but > once you've enumerated them all, updated your SPF record and/or made sure > they're all properly DKIM signing, you can skip right from p=none to > p=reject. > > I look forward to lively conversation... > > -- > > *Todd Herr* | Technical Director, Standards and Ecosystem > *e:* todd.herr@valimail.com > *m:* 703.220.4153 > > 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. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
- [dmarc-ietf] Priming the Pump for Discussion - Ra… Todd Herr
- Re: [dmarc-ietf] Priming the Pump for Discussion … Dilyan Palauzov
- Re: [dmarc-ietf] Priming the Pump for Discussion … Alessandro Vesely
- Re: [dmarc-ietf] Priming the Pump for Discussion … John Levine
- Re: [dmarc-ietf] Priming the Pump for Discussion … Douglas Foster
- Re: [dmarc-ietf] Priming the Pump for Discussion … Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Todd Herr
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Douglas Foster
- Re: [dmarc-ietf] Priming the Pump for Discussion … Steven M Jones
- Re: [dmarc-ietf] Priming the Pump for Discussion … John Levine
- Re: [dmarc-ietf] Priming the Pump for Discussion … Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Todd Herr
- Re: [dmarc-ietf] Priming the Pump for Discussion … Jim Fenton
- Re: [dmarc-ietf] Priming the Pump for Discussion … Jim Fenton
- [dmarc-ietf] Fwd: Priming the Pump for Discussion… Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Douglas Foster
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Barry Leiba
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dotzero
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Benny Pedersen
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dotzero
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 tjw ietf
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Laura Atkins
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Douglas Foster
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Steve Siirila
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Dave Crocker
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Laura Atkins
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Laura Atkins
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Matthäus Wander
- Re: [dmarc-ietf] Fwd: Priming the Pump for Discus… Barry Leiba
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Alessandro Vesely
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 John Levine
- Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99 Дилян Палаузов
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… John R Levine
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Benny Pedersen
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Douglas Foster
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… Alessandro Vesely
- Re: [dmarc-ietf] From: munging, was Ratchets - Di… John Levine