Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
Mark Alley <mark.alley@tekmarc.com> Wed, 29 March 2023 22:50 UTC
Return-Path: <mark.alley@tekmarc.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 4763DC15170B for <dmarc@ietfa.amsl.com>; Wed, 29 Mar 2023 15:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tekmarc.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIgUkhxBjJKx for <dmarc@ietfa.amsl.com>; Wed, 29 Mar 2023 15:50:49 -0700 (PDT)
Received: from mail-yw1-x1141.google.com (mail-yw1-x1141.google.com [IPv6:2607:f8b0:4864:20::1141]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48116C14F736 for <dmarc@ietf.org>; Wed, 29 Mar 2023 15:50:49 -0700 (PDT)
Received: by mail-yw1-x1141.google.com with SMTP id 00721157ae682-5416698e889so322089837b3.2 for <dmarc@ietf.org>; Wed, 29 Mar 2023 15:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tekmarc.com; s=google; t=1680130248; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=kQY5eHlEVre+y5dds09MvH9JonC07PUcpA7jEeyXiEw=; b=Pe0OONkLQw1lXMXkFKMPAWfYp79Tv0svSx/yvPcp2JdMKZ8HtzrtAkXDplHh1Wy5VE VxJd0FQgKu2cuLn4abiZ9M92g5Fs8oIXdmcrp+lD4OSOt2elcXe5bIw8kyQ2iE7jE82V nyWYyTFq3ZebxuGwWxUdlGKPPktGRfdo0BSpj7Mg10jBMRY1yGOCBMm3HIsYbPIf2yM9 vUqumO8napdQvg/LhBergV4H4nZF0q1sbX1nfhX67XTQIrPWMRmPzQgSn1Avbsr9Fbzc D0huPzxeTXwEiPuxeJ6ufE87gn1R0onz4smQeg3fpKk+eQQHzHicz1HMKxNdow7bzEXm CbLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680130248; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=kQY5eHlEVre+y5dds09MvH9JonC07PUcpA7jEeyXiEw=; b=6RVf/JpcRegTRhesBiG2QneICM43dp0Xgnifm7qdFnBcGCxFaWCrSx56OOroqtrOhD +2WkqwT/7pdjxWZtoabOanARXz5vM78hv+EhHC+ZbN9YutemunmLeuVbSKBfB18UIFFC uCtoGw5hcyIR2sNBXISy7NvTD+CqFgFkNVZo/MjCS1QGeoj+vUB7J9W7M7c1dQeY0jDr OFZHBvt5lPMR7B1edPVv94OHdDLcVlUp2xLDs3p0J4mbriHcKIBXxOQxEJrEvV3f0UYg 3+fjDPBTbBZqcvS8SyiUDuRwe/qsUfhCVwfypALB1sfK2HV4CbAbd6UmtddO7/ztkpJe lTFA==
X-Gm-Message-State: AAQBX9c3t7zf6nMv4nIfDFQP0e+OWTFVXJHEC7a9i95eZeyQGJ01Biyx hkQ8w86cS1pyP25A2ADLQLOrJ8gZbUMzAcaGlU9VM63E5Bs=
X-Google-Smtp-Source: AKy350bFNeOqPeE0BovNaO2jv/FGZ3ag4NvFyWKam+Py+4BT/SKFnvVEDgqvMmpTH91fdnrrJjtShw==
X-Received: by 2002:a81:6803:0:b0:541:8ae4:e63e with SMTP id d3-20020a816803000000b005418ae4e63emr18719340ywc.16.1680130247709; Wed, 29 Mar 2023 15:50:47 -0700 (PDT)
Received: from [192.168.2.20] (162-238-103-217.lightspeed.brhmal.sbcglobal.net. [162.238.103.217]) by smtp.gmail.com with ESMTPSA id v14-20020a81b80e000000b005460e4170e4sm1048460ywe.129.2023.03.29.15.50.46 for <dmarc@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 15:50:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------rMpRGOmA0GzhncjHov6uBZ1l"
Message-ID: <d77e524f-bfb2-b075-5517-8f2a6058c064@tekmarc.com>
Date: Wed, 29 Mar 2023 17:50:46 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0
Content-Language: en-US
To: dmarc@ietf.org
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <6319292.vCqnBZbX7o@localhost> <CAHej_8nd1xyAgwASLJbuJHyXEAfHbjqxNH1XtJxKFyfyOneyug@mail.gmail.com> <13145172.pEV04Z3DvM@localhost> <CAHej_8msLJQ0vbZ2jzitjxrQ1wdim5bHJkiD-QrU5F0EJvQp0g@mail.gmail.com> <FCFEB95E-63F9-46C3-A5F4-FA6B02FA8EB5@episteme.net> <CAHej_8=GbmzyXaeEkyLkv6uKc0-owuMC6UspPNq9irT7nF8b7w@mail.gmail.com> <CALaySJLmRyyBLE7ZKy88XUS_hXr9M2uwc8jOCYBrBPeC+pCdCg@mail.gmail.com> <MN2PR11MB43519A6CD95E5C80AA1EC2CFF7899@MN2PR11MB4351.namprd11.prod.outlook.com> <13603D87-4FDE-4768-9712-E6DB0818C802@kitterman.com>
From: Mark Alley <mark.alley@tekmarc.com>
In-Reply-To: <13603D87-4FDE-4768-9712-E6DB0818C802@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fj2YY8YQpPIXovUaRkyCDT-5IiM>
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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, 29 Mar 2023 22:50:53 -0000
I have a question for the group; I have read RFC7960, but I feel my question merits reiteration for those of us on this list (like me) that may have differing opinions on this topic from experience as a consumer of the standard, and having worked with many of these "general purpose" domains at p=reject. The concern with interoperability with p=reject is that if, hypothetically, every domain on the internet were to go to p=reject right now, the damage would be tangible because many indirect and "non-DMARC described" mail flows would be prevented from delivery? (non-5322.FROM munging mail lists, some non-descript mail relays, a random mailbox forwarding, a non-DKIM preserving forwarding mail service, non-DKIM signed forwarded mail flows, etc. etc.) Is this a correct assessment behind the reasoning for the "MUST NOT" language? I am concerned that others may see this language and perceive it as weakening the value of DMARC, or that DMARC should not be implemented at all, when there is a proven track record of many <general purpose> domains that have implemented strict policies to great effect in securing their domains without major issues. ----- Separately, from a "general purpose" domain owners perspective, I share Alex's thoughts. Having worked with many (extremely high volume) non-transactional domains at p=reject, the noticeable issues caused from p=reject has been negligible to these organizations. Many of the mitigations from RFC7960 already apply to the traffic that would have otherwise been impacted by what would normally be considered an interoperability issue otherwise. That is not to say there is not /any/ impact from its implementation, but from an organizational standpoint, all the important messages are still delivered. There have been outliers, of course, but they are dealt with by the organizations on a case-by-case basis, which, to date, have been less than a handful. - Mark Alley On 3/29/2023 3:59 PM, Scott Kitterman wrote: > Would you feel any better if the MUST NOT was followed by 'to preserve interoperability '? That's implicitly there and I believe technically correct. If you value other properties of the system higher than interoperability, then the advice may not apply, which is fine. > > Scott K > > On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex"<Alex_Brotman=40comcast.com@dmarc.ietf.org> wrote: >> I’m just not sure how we determine what is high-value. >> >> comcast.com: p=reject >> comcast.net: p=none >> xfinity.com: p=quarantine >> >> The top one is corporate, middle is consumer, bottom is consumer (but not actually used) & customer comms (sub-domains). They’re all used in various ways for internal messaging. Should I tell our corporate admins that they need to no longer publish p=reject? They’re violating the RFC by doing so? There are very few consumer-oriented messages that originate from comcast.com. Are we doing it right? It makes things a little harder when one of our employees wants to use a mailing list. But that still feels like the right thing to do. >> >> If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating to domain owners what is in their best interests, regardless of our perceived value of their domain. >> >> -- >> Alex Brotman >> Sr. Engineer, Anti-Abuse & Messaging Policy >> Comcast >> >> From: dmarc<dmarc-bounces@ietf.org> On Behalf Of Barry Leiba >> Sent: Wednesday, March 29, 2023 10:15 AM >> To: Todd Herr<todd.herr=40valimail.com@dmarc.ietf.org> >> Cc:dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows >> >> I'm very much against text such as this, as I think it encourages deployments that are contrary to interoperability and to the intent of p=reject. >> >> I contend that p=reject (as with the similar construct in the older ADSP) was intended for high-value domains and transactional mail, and that it was never intended for use in domains where general users send general email. >> >> I stand by the MUST NOT that I proposed. >> >> Barry >> >> >> On Wed, Mar 29, 2023 at 10:33 PM Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org<mailto:40valimail.com@dmarc.ietf.org>> wrote: >> On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick <resnick@episteme.net<mailto:resnick@episteme.net>> wrote: >> >> If you agree that interoperability is increased, then I'd suggest that you actually do agree that the proposed text is appropriate. >> >> >> I don't know that I agree that interoperability is increased... >> >> I'm having trouble squaring proposed language that says "Domain owners MUST NOT publish p=reject because it breaks interoperability" with the following language from section 5.8: >> >> >> Mail Receivers **MAY** choose to accept email that fails the DMARC >> >> mechanism check even if the published Domain Owner Assessment Policy >> >> is "reject". In particular, because of the considerations discussed >> >> in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject >> >> messages solely because of a published policy of "reject", but that >> >> they apply other knowledge and analysis to avoid situations such as >> >> rejection of legitimate messages sent in ways that DMARC cannot >> describe, harm to the operation of mailing lists, and similar. >> >> It seems inconsistent to state with certainty that authorized mail will be rejected due to authentication breakage when there is no requirement that a reject policy be honored (and we have plenty of evidence that Mail Receivers are following the 'SHOULD NOT reject messages' guidance). >> >> Language that would be more consistent in guidance to the domain owners might look something like this: >> >> After careful analysis of the aggregate report data as described in section 5.5.5 >> (Collect and Analyze Reports), Domain Owners **MAY** choose to change their >> policy from 'none' to 'quarantine' or 'reject'. If, in the Domain Owner's judgement, >> unauthorized and deceptive use of its domain name in the RFC5322.From field puts >> at risk the trust it has built with its recipients, then it is **RECOMMENDED** that >> the Domain Owner make use of the p and/or sp tags to set policy to 'quarantine' or >> 'reject' for those streams most at risk of loss of trust. >> >> If going that route, probably want to consider expanding on 5.5.5, too; I need to think about it some more. >> >> -- >> Todd Herr | Technical Director, Standards and Ecosystem >> e:todd.herr@valimail.com<mailto: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<mailto:dmarc@ietf.org> >> https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!BnSVJ7Ot7xEorNxvwnQPPLKjCUoG0MiUMFnPczO18L4RV-xRev7lnYcl6buwUHNn4JbzvGlzqAMl2J5l4bHsMbKOXw$> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc
- [dmarc-ietf] Proposed text for p=reject and indir… Barry Leiba
- Re: [dmarc-ietf] Proposed text for p=reject and i… Jim Fenton
- Re: [dmarc-ietf] Proposed text for p=reject and i… Todd Herr
- Re: [dmarc-ietf] Proposed text for p=reject and i… Mark Alley
- [dmarc-ietf] DMARCbis and M3AAWG Email Auth BCP (… Todd Herr
- Re: [dmarc-ietf] Proposed text for p=reject and i… Todd Herr
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Brotman, Alex
- Re: [dmarc-ietf] Proposed text for p=reject and i… Dotzero
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Todd Herr
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Todd Herr
- Re: [dmarc-ietf] Proposed text for p=reject and i… Brotman, Alex
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Pete Resnick
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… John Levine
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Todd Herr
- Re: [dmarc-ietf] Proposed text for p=reject and i… Barry Leiba
- Re: [dmarc-ietf] Proposed text for p=reject and i… Brotman, Alex
- Re: [dmarc-ietf] Proposed text for p=reject and i… Todd Herr
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Mark Alley
- Re: [dmarc-ietf] Proposed text for p=reject and i… Barry Leiba
- Re: [dmarc-ietf] Proposed text for p=reject and i… Barry Leiba
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… John Levine
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Barry Leiba
- Re: [dmarc-ietf] Proposed text for p=reject and i… Pete Resnick
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Dotzero
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] THIS IS ABUSE (no it's not) Scott Kitterman
- Re: [dmarc-ietf] Understanding Ale's Abuse resear… Douglas Foster
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Alessandro Vesely
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Mark Alley
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Eric D. Williams
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… John Levine
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Alessandro Vesely
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Scott Kitterman
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) John Levine
- Re: [dmarc-ietf] THIS IS A DISTRACTION (it might … John Levine
- Re: [dmarc-ietf] THIS IS A DISTRACTION (it might … Scott Kitterman
- Re: [dmarc-ietf] THIS IS A DISTRACTION (it might … Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Dotzero
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Mark Alley
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Dotzero
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Neil Anuskiewicz
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Matthäus Wander
- Re: [dmarc-ietf] Proposed text for p=reject and i… Jesse Thompson
- Re: [dmarc-ietf] Proposed text for p=reject and i… John Levine
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Hector Santos
- Re: [dmarc-ietf] Proposed text for p=reject and i… Barry Leiba
- Re: [dmarc-ietf] Proposed text for p=reject and i… Hector Santos
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Neil Anuskiewicz
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Matthäus Wander
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Alessandro Vesely
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) John R Levine
- Re: [dmarc-ietf] Proposed text for p=reject and i… Mark Alley
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Laura Atkins
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Laura Atkins
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) Eric D. Williams
- Re: [dmarc-ietf] THIS IS ABUSE (it might be) John R Levine
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Laura Atkins
- Re: [dmarc-ietf] Proposed text for p=reject and i… Dotzero
- Re: [dmarc-ietf] Proposed text for p=reject and i… John Levine
- Re: [dmarc-ietf] Proposed text for p=reject and i… Dotzero
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Douglas Foster
- Re: [dmarc-ietf] Proposed text for p=reject and i… Murray S. Kucherawy
- Re: [dmarc-ietf] Proposed text for p=reject and i… Emanuel Schorsch
- Re: [dmarc-ietf] Proposed text for p=reject and i… Dotzero
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Mark Alley
- Re: [dmarc-ietf] Proposed text for p=reject and i… Laura Atkins
- Re: [dmarc-ietf] Proposed text for p=reject and i… Wei Chuang
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Jim Fenton
- Re: [dmarc-ietf] Proposed text for p=reject and i… Jim Fenton
- Re: [dmarc-ietf] Proposed text for p=reject and i… Mark Alley
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Scott Kitterman
- [dmarc-ietf] Search for some consensus, was: Prop… Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … John Levine
- Re: [dmarc-ietf] Search for some consensus, was: … Hector Santos
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Hector Santos
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Alessandro Vesely
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Hector Santos
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … John Levine
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Jim Fenton
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Hector Santos
- Re: [dmarc-ietf] Search for some consensus, was: … Brotman, Alex
- Re: [dmarc-ietf] Search for some consensus, was: … Alessandro Vesely
- Re: [dmarc-ietf] Search for some consensus, was: … Alessandro Vesely
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Jesse Thompson
- Re: [dmarc-ietf] Search for some consensus, was: … Alessandro Vesely
- Re: [dmarc-ietf] Search for some consensus, was: … Alessandro Vesely
- Re: [dmarc-ietf] Proposed text for p=reject and i… Alessandro Vesely
- Re: [dmarc-ietf] Search for some consensus, was: … Scott Kitterman
- Re: [dmarc-ietf] Proposed text for p=reject and i… Hector Santos
- [dmarc-ietf] Summary: Search for some consensus, … Scott Kitterman
- Re: [dmarc-ietf] Summary: Search for some consens… Douglas Foster
- Re: [dmarc-ietf] Summary: Search for some consens… Hector Santos
- Re: [dmarc-ietf] Summary: Search for some consens… Douglas Foster
- [dmarc-ietf] Add MLS/MLM subscription/submissions… Hector Santos
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Douglas Foster
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Emanuel Schorsch
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Douglas Foster
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Alessandro Vesely
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Douglas Foster
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Hector Santos
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Brotman, Alex
- Re: [dmarc-ietf] Add MLS/MLM subscription/submiss… Hector Santos
- [dmarc-ietf] Fwd: Summary: Search for some consen… Scott Kitterman