Re: [dmarc-ietf] ARC vs reject

Michael Thomas <mike@mtcc.com> Mon, 07 December 2020 05:42 UTC

Return-Path: <mike@fresheez.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 DCB893A102F for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 21:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.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 BbKSNf7b_Sr9 for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 21:42:56 -0800 (PST)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 6C43F3A102C for <dmarc@ietf.org>; Sun, 6 Dec 2020 21:42:56 -0800 (PST)
Received: by mail-pf1-x42b.google.com with SMTP id q22so8661570pfk.12 for <dmarc@ietf.org>; Sun, 06 Dec 2020 21:42:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=uq4K/DSQLryadT078aK+L5Jq+JuwZ0Ly5quePRCyNps=; b=spIEEBloiQcUJ6haJvcJ14skr7ph0xjWESZd2HN1sT8d14QPyXTquNzM4HALVy/yWO 9bIU121nEzmhXELyJ+an9Mi22qqEtjDc2eLpVz+G+NfMM82IcwcyIcLe89Vx75aOkU68 SEX5RmyqrmgsyhLhTi6gfybplrpTyz43HnWjcnZhF9KniLhxzLXNtX76WJqTaK0W2SVw t4Jzpk+VV1PAxA7mL0lbrPPZG4VsJRGDai6qHGYgrsXD2yl0vuV4mM6ttYdzx+EdILwd g3pDJHyZi+8+/13GVGQvcV4Z2BjZmOT09yQvfwxvetnRvvDBEbIX3dE67AwoLuZlMDiR nK0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=uq4K/DSQLryadT078aK+L5Jq+JuwZ0Ly5quePRCyNps=; b=KxPegVWktZQZ6ZzzKHSUNgNpG625iJbcpiJv93IE3o/svMtlacJ8oJLpIEYmbk/gr3 PNlxW1MGyEhBskNlhWxszMsW44IXakV6cj4NZXBPbD2MKstYQ6lQki5Pj39dz22Z3vqv nbyUueLbHr/BcTSo09S4MTtOYyVMtlJJJ+yh+hPnTI+NwMeC3dBv+Ww7BmLkdiR3Yr8O n0RxlD5aFpgT+WWIsLTHTzSNkBj2eZhTEaoelnkLzlOXB3Izv5QNS+KC3DnblR8TfjE4 8PcRsSilI2PixuE75H74J+4L5h+GOCscBwn8sAE4LWwT/MkVydZVirYbOboFT244MQTa Tqpg==
X-Gm-Message-State: AOAM533aetbWTmuq/iOfiPkjfM3hoL7H8Y+8hdvlA4TSaqPEZHOc3/VA vfrTEAikIW9P+qwKcnYoLYJBS7RFpTIqTA==
X-Google-Smtp-Source: ABdhPJzAl13W2bKXcLibOwlKYX4uDqrpE7QDISsESVBa1Ey7zbW8olkJUlYQHr4YhWrkql2Inh1IrQ==
X-Received: by 2002:a17:902:a502:b029:da:f580:bc35 with SMTP id s2-20020a170902a502b02900daf580bc35mr3804118plq.60.1607319775292; Sun, 06 Dec 2020 21:42:55 -0800 (PST)
Received: from mike-mac.lan (107-182-42-108.volcanocom.com. [107.182.42.108]) by smtp.gmail.com with ESMTPSA id f9sm2558137pfa.41.2020.12.06.21.42.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 21:42:54 -0800 (PST)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> <A7E1018B-F6B1-46F3-8FEF-69FDC744DA4A@bluepopcorn.net> <d8dc2644-cbcf-d3a1-c5fb-46fdf5bec819@taugh.com> <CAH48ZfxWWxSh3j3YnA4eD4Y5Ep4GfVDr22WX1MCM4-tcVK0UpQ@mail.gmail.com> <b5774a04-fbee-8d23-d760-0380d58a9fb7@mtcc.com> <CAL0qLwZ+KFrPzScr6c-tMOd2nCV=v1Mf71h0fWBUV9_ZZ-k6Cw@mail.gmail.com> <be9ddc32-8709-0990-c663-5c625efd6b1f@mtcc.com> <CAL0qLwYNzkt7afY4ssRKtgpfBSQXxcyuNTQ++7QkUaO0GA9=Kw@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <5ece3b4d-bdc4-ca57-d54a-3186efac8007@mtcc.com>
Date: Sun, 06 Dec 2020 21:42:52 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwYNzkt7afY4ssRKtgpfBSQXxcyuNTQ++7QkUaO0GA9=Kw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A9DC0C038C0FCC8277F26C4C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ePkJEl3KoTWyhsn7qp-d3RkkdtM>
Subject: Re: [dmarc-ietf] ARC vs reject
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: Mon, 07 Dec 2020 05:42:58 -0000

On 12/6/20 9:30 PM, Murray S. Kucherawy wrote:
> On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <mike@mtcc.com 
> <mailto:mike@mtcc.com>> wrote:
>
>     An idea that i've been rolling around in my head is that the MLM
>     could give a sed-like script to rollback the changes. since they
>     know their modifications, they can obviously express how to
>     unmodify them. it may have less issue with the mime hackery you
>     were thinking about.
>
>
> You'd need a way to assert, and then evaluate, that something 
> equivalent to "s/.*/spam/g" is a transformation you're not willing to 
> reverse and say "yep, we're good."  I don't know how you'd go about 
> automating that.


yes, definitely. but that's just as true of your draft. these are all 
heuristics at some level to feed into some hypothetical filtering 
machine to make sure there is no fuckery going on. such is the nature of 
spam filtering. i think that is the part that is hard thing to swallow 
from a standards standpoint and is what causes so much roiling. it's 
hard for me to say if that's a good thing or a bad thing.

>     But as far as your point about spam vectors it is surely just as
>     true about ARC, right? at least with recovering the original text
>     i have the ability to remove all of the transforms and deliver the
>     original text.  ARC not so much. it's all or nothing on the trust
>     front.
>
>     But I really think the key thing about all of this is figuring out
>     what defines success. That is the most important thing by far.
>
> I think ARC, like PSD, is meant to run for a while and see what we've 
> learned from it.  Maybe it's the silver bullet, or maybe it's 
> ineffective complexity.  That should be part of the experiment's 
> definition; Section 11 of the ARC RFC does try to capture all of that.
>
As I've been harping on, we need to have an agreed on definition of 
success. We know that 100% is not among them. What in the long tail 
don't we care about?

Mike