Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
Douglas Foster <dougfoster.emailstandards@gmail.com> Sat, 08 April 2023 21:27 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 2EBADC151B0A for <dmarc@ietfa.amsl.com>; Sat, 8 Apr 2023 14:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=gmail.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 mccz8SEi2ucA for <dmarc@ietfa.amsl.com>; Sat, 8 Apr 2023 14:27:39 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 7F5A6C151B09 for <dmarc@ietf.org>; Sat, 8 Apr 2023 14:27:39 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id y4so1757475ljq.9 for <dmarc@ietf.org>; Sat, 08 Apr 2023 14:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680989257; x=1683581257; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=2YNXsjZTScQxHVWoha6zDl1CnqcA3qitTrmGVROFASc=; b=iv4mIM43k51jejXvPsKIhngQviOHacbe8M0SkFJV17odkLV5ZCCpwuTve9P/iEvhH2 07NXvCbjfseBX7EtdCAHZ8GUpl42nkxGL+1CccQTvEmDUWUhJZGAn5XeVUaF1yWgEXo4 W2xVh/gNIefYyX94byjquKocI9aC7NeTDcBKNl+Q2/61dBx10rWldfLP4ll2rYEMgqnf MBk4QUTDZm5PIzn//nAEcOEwX8HuBwXhm9GKvuqLu+ZlanLrdtANtNTA7RHewT5PnkRE w48KigXAXEpNqL85Ksy6zYW+xM0/VOWa2VPnU+2uojn29K4EWHvoVCfelxrouou3hz2b ZNnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680989257; x=1683581257; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2YNXsjZTScQxHVWoha6zDl1CnqcA3qitTrmGVROFASc=; b=b7OaPuW7k+kr4hok26QcSx8qXKL9/l82McZnirMHFREhur1upxqudH39rFs4GAbSov 7IYbWNnu2vN0Uu3pT7WOsCixQtMvm76gAJ0O3LoKsxZxnOjvl/gwZ8wKCJTHfP7HHVTq mC1NAlBdhjMwdAspgny384MXipnDK/MF8kBAW7WuQWUl0tmCuODlmaLHG4kHbNGf4F3B 7J5Vg66IZNakTOESxz0l96TUKQeCO8gWzdInStPzzGTD1E7KoTEwMNhR+jtFq0OJw7ze flGT2BvDHuR5ji07KmIuZObobWlL7JVaSMl/XMMUc7LZbLsaJBSumsBlXtkIYmqR5V4r hoZg==
X-Gm-Message-State: AAQBX9d/DwA5h1aFCLdSfssAdg9o8oBZHGwnnnPzCuO4LITkFwEtlqM7 exf0gNbI/owEihnW2COg+pzi0EeRYjaZmh885Qnw1AP/
X-Google-Smtp-Source: AKy350ZTSsSW0aFtdAf3wWe+fm2wWRLk1NNo8LxN3raCQEUwaQ08IRIBP+eM4uX8/OnOK/1EkEOx5Cc1upy6aFGq8j8=
X-Received: by 2002:a2e:9c0e:0:b0:2a6:16b5:2fba with SMTP id s14-20020a2e9c0e000000b002a616b52fbamr1595099lji.1.1680989257195; Sat, 08 Apr 2023 14:27:37 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <13603D87-4FDE-4768-9712-E6DB0818C802@kitterman.com> <CALaySJLY-9O1Wauk50WMMobNs3cKUzmB+=np080nYCHEZa32UA@mail.gmail.com> <3129648.WqDQmVRvLn@localhost>
In-Reply-To: <3129648.WqDQmVRvLn@localhost>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sat, 08 Apr 2023 17:27:26 -0400
Message-ID: <CAH48ZfzwUTtzcn3Us+_u7NwMHqjp8UavyrDEPQndXUtUFk4O1w@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008be2bd05f8d9cf9d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Th6WQuT5zcPcbQME5ezyv2M5PJI>
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: Sat, 08 Apr 2023 21:27:44 -0000
I rather thought all of the recent discussion is on the general topic of what to do about mailing lists, and that we were still a long ways from consensus, as we were three years ago. For my part, I have a hard time accepting the concept that there are meaningful distinctions between high, medium, and low value targets. Malicious impersonation is a problem, regardless of the domain used for that purpose. Which domain is useful to the spammer depends on who he is attacking at the moment, and everyone gets attacked. I also have a hard time with the notion that any domain with a potential exception becomes a domain that MUST NOT protect itself from impersonation. It seems like essentially every domain has a potential exception, so this becomes a directive to warn people away from DMARC completely. Some participants would doubtless like that outcome, but I don't see any likelihood that DMARC can be killed. Email delivery is the digital version of a stare-down contest. Evaluators have a take-it-or-leave-it choice on every message. We don't have the option of asking, "Can you provide a little more information here? Can I see your identity card? Can you explain the purpose of this message?" Similarly, the sender launches messages into the wild hoping that they will actually be delivered, and sometimes working furiously to figure out if that actually happened. If his message is blocked, he has few if any way to ask for reconsideration. In the current situation, AOL has won the stare-down contest, because they refuse to blink. We need to figure out how to make messages acceptable to them, and abandon hope of getting them to change. If they were interested in changing, they might make an occasional contribution to this list so that we would know what would be acceptable to them., In my world, when an employee thinks a message was blocked incorrectly, he complains, we investigate, and we make adjustments. For some recipients, this process apparently breaks down. We seem to assume that if the sender adds one or more additional layers of complexity, this breakdown between evaluator and domain member can be prevented by outside action. I am skeptical that it will be that easy. Mailing lists have some unique problems. They have messages from multiple author domains being transmitted to multiple recipient domains. Since every domain has unique filtering rules, it is predictable that the list will have a continuing series of problems with a subset of messages being blocked by a subset of evaluators. RBLs are one way this can happen - different domains reference different RBLs, so a sender may be blocked (correctly or incorrectly) and rejected by evaluators using one RBL, but allowed by evaluators using another RBL. Even when the recipient and the evaluator have a great working relationship, neither party may understand what exceptions are needed for the messages from every participant, current or future, to be accepted reliably. So the list messages arrive smoothly until a message is sent from a participant in a geo-blocked country. The user discovers the problem when he realizes that he has no idea what topic is being discussed, because he missed the initial post. t seems evident that to get consistent evaluation results, evaluators need to judge based on the list identity and reputation, rather than the sender identity and reputation. I do not see how this can be achieved without replacing the From address with an address in the list domain. Replacing the From address is not the only obstacle, but it is the starting point. Doug Foster On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman <sklist@kitterman.com> wrote: > We've gone nearly a week without any further discussion on this thread. > > I reviewed the thread and I think this is the closest we got to anything > (most) people agreed on. I know not everyone liked it, but I doubt we're > going to get closer to a consensus on this. > > Can we adopt this and move forward on to the next thing? > > Scott K > > On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote: > > I'm happy with that suggestion. > > > > Barry > > > > On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman <sklist@kitterman.com> > 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.iet > > > >f.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. > > > > > > _______________________________________________ > 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