Re: [dmarc-ietf] ARC vs reject

Dotzero <> Mon, 07 December 2020 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46EEF3A0978 for <>; Mon, 7 Dec 2020 04:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qdShlcX7eSYB for <>; Mon, 7 Dec 2020 04:05:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1DD63A064B for <>; Mon, 7 Dec 2020 04:05:41 -0800 (PST)
Received: by with SMTP id k4so9136629qtj.10 for <>; Mon, 07 Dec 2020 04:05:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xs/Jz6a3XbTTjRCIm97Em4lm6sTladTcVXWPWtzOyPs=; b=ulR16E4+WqF7li7RhZnjWyPlRcow6xAfpe9LdyyiUROb0XqcIMWywa52c2sD92+vdx /3nDWX3KDPOqat/JCKven+NljYTCO25ULsEaM42aNl1ArOwa0hR/DNVl+3xjs+3WO9Y3 GHxwmMyEqM1lP3GYxrlPgpfGS05TrQdDn9oR7YCPE3jmtne2aIqCYCMWbsGebYJiXm4y 1spx6JaHGtFPqYJFbV+dPOFFiUFYjWBo1rO7nCL+3X2s7p5yi6VCaPidLk8e1fyKE0JP wucLJiGSo8BmyJkBhuyK2azHAW4pHZJ1D8KQDOYdB3v0DBOkUuJyIaq6qZAmxuG0a6e7 eYQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xs/Jz6a3XbTTjRCIm97Em4lm6sTladTcVXWPWtzOyPs=; b=rdRZ6YgABlLsTasiBufRQsktzLEN7GWphpPUF5A1vLit9iP4J1XK2lgtl9N8+Ggg+t 69tnWJGqELQAtvHuzAs2tRedj2Z/HBd3OOTW/1ffl9fbXuiIxPT0g5EmZXm69cMw6ZXd 3q3GJNeVbfsBup/7eBrv81Lgr7Fj+ljTi8w+9FtHbV7PQC67YcIr5bLM4DZ8MPJX3AVr PZzjvHZZAQh8kXpaSjToZ+w9lhgdybQDlu1polNgX+RgrU9ilppZvY7UeKooNF2Mpncl gHmJ/FbN9d29wk7yXa+vTvqsa5hpx494FtrVvM/qCoeVMj4QX151Qz0ry9MQRlN2p2DB 53lA==
X-Gm-Message-State: AOAM533RNt7ztTESm6ciNp4Fck+K4dBIWOVNQHLsz3PmGo2tWGbvpVun S1Z7D73H/x8QAiksiDGt3Vwnwf6qmYA0wZ6vw60=
X-Google-Smtp-Source: ABdhPJxo4QQKNR014TvOK/imCr/w1vMLT5/w71NsF1OpBgFdcXCNtysfFk8eUXFZIRqrQh05BL/9+iss0dVB9zupxBo=
X-Received: by 2002:ac8:5412:: with SMTP id b18mr23428376qtq.220.1607342740767; Mon, 07 Dec 2020 04:05:40 -0800 (PST)
MIME-Version: 1.0
References: <20201205210351.DB78E2904420@ary.qy> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Dotzero <>
Date: Mon, 7 Dec 2020 07:05:29 -0500
Message-ID: <>
To: "Murray S. Kucherawy" <>
Cc: Michael Thomas <>, IETF DMARC WG <>
Content-Type: multipart/alternative; boundary="00000000000018889505b5dea5c0"
Archived-At: <>
Subject: Re: [dmarc-ietf] ARC vs reject
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Dec 2020 12:05:43 -0000

On Mon, Dec 7, 2020 at 12:30 AM Murray S. Kucherawy <>

> On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <> 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.
>> 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.

I've asked here and in other places that validators/receivers consuming ARC
headers provide data regarding the results of such consumption. To date we
have not seen any data provided by participants in the ARC experiment. It
may be that ARC is a useful standard or it may not be. So far I'm seeing a
lot of supposition and speculation but no useful data for evaluation.

Michael Hammer