Re: [dmarc-ietf] ARC vs reject

Douglas Foster <> Sun, 06 December 2020 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2AE03A09C1 for <>; Sun, 6 Dec 2020 10:45:50 -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 jmLF4Qn4j1Jp for <>; Sun, 6 Dec 2020 10:45:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E65C3A09BD for <>; Sun, 6 Dec 2020 10:45:48 -0800 (PST)
Received: by with SMTP id z16so6356803vsp.5 for <>; Sun, 06 Dec 2020 10:45:48 -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; bh=tYCEE10dd77ktelR+OfVD9Mv8KrOTDhhJZkBciSybqI=; b=bRnNGm8Mzgk8dOvZqgqUQzzsXVxJTseJwDTWa1pOeFDGbk2qAZtSCpE0kRBqUav7IV wyYkFdtKNw5k6JF6cgIkmeJoOMeyl1WFWQ3fGslmZxlecF68QFnh+IXW72imAcbehSUD 76yEmM8ZcWxlPWsf4i1HElKRHtQT/HiBk3l1wjirdOdzOgcwiPtGOXr+hYMOp2luP0g+ HVivKh23rCPQrodmjr7TBDsW/IxrbC4CCje7qEo6AiFt9iS/GIOKenwQzU/NouajkMng Lwye9wzX94TJGOcpe97Cwtda3YdzrhsVlNI3TCymOuFrdUE2/Rd4X+cz1Rq17I5mbDbR xJkQ==
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; bh=tYCEE10dd77ktelR+OfVD9Mv8KrOTDhhJZkBciSybqI=; b=lllCa09cs5O+IC6zk+1FJld4asNlK3ev0MPCSIkQ143LlKiYFVK9kMZ78/VJj1O1N+ mEwG7Rzj5FkOZx3rnOydPRKvy78Kyoich/d11CHha3nalshIEMrFpcXGbFa8tLrkGUTF Hw0tb0pt5xyM6tzrPYkaab2NZ3pUjBA9xLsBrdh9hkFnkueukV3aWEjVPFHVdHkSsqeL CS9KN0bHexb+2I7a0UGSlqIRmv7X4mzlVme0l3ztr+VDo1+1l9o26CjSClRzbK9FMxqq /1GIPGXbcV4yXEyOYwH6eeb80va0Z3ylEFJgOJBBmMT8avf3p2mfJRE5MbluT45l+9MV Dbag==
X-Gm-Message-State: AOAM532dE7SZA5PraGyj9hf+wjT8In8mKFlYdPdvKu3O07S0uonubgyv UOy2SRSuNl5Pj8046GBKGeVrb4Xb1+3/ZZjX8EiKWzJq9MI=
X-Google-Smtp-Source: ABdhPJx6c1q8BUQ6V8ouk4gxz9ZJ6PmJLcz1vh6IsOQXraFHAD82AG0ZHYmiJuGDQngZXjugtYMSCL8kefdn+XKtGWQ=
X-Received: by 2002:a67:fad2:: with SMTP id g18mr10692013vsq.45.1607280347493; Sun, 06 Dec 2020 10:45:47 -0800 (PST)
MIME-Version: 1.0
References: <20201205210351.DB78E2904420@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Sun, 6 Dec 2020 13:45:36 -0500
Message-ID: <>
To:, dmarc-chairs@ietf.ord
Content-Type: multipart/alternative; boundary="0000000000002ab8bb05b5d01e55"
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: Sun, 06 Dec 2020 18:45:51 -0000

The recent discussion has introduced two challenges to ARC:  first, that it
is too complicated, and second, that it opens up security holes that should
be unacceptable.    John's response appears to be that the technology will
only be used by a small group of lists in cooperation with a small group of
recipients, that the complexity will be a non-issue for the participants
and the risk, while present, will be mitigated by the limited scope of
participation.    All of this is problematic.

On security issues, we have to assume attacks by state-sponsored actors,
not just fortune seekers.   So the security challenge needs to be
thoroughly vetted.

But the participation assumption is even more worrisome.    If this is a
limited participation protocol, supported by a private but not-yet-created
communication network, then it does not solve the chair's requirement for a
general solution.

I ask the chairs to formally endorse development of an alternative to ARC
as an additional approach to the mailing list problem, a solution based on
reverse transformation.   Alessandro and Murray have submitted drafts.   It
is time to study their proposals and merge their work.

Doug Foster

On Sat, Dec 5, 2020 at 11:14 PM John R Levine <> wrote:

> On Sat, 5 Dec 2020, Jim Fenton wrote:
> >> Of course not.  That's just the tiny gorillas stamping their teensy
> feet.
> >> Why would anyone expect that the people publishing that flag actually
> >> understood what it meant?  Many will just turn it on because someone
> said
> >> it's "more secure."
> >
> > FWIW, I don’t think a lot of the people publishing p=reject understood
> the
> > implications of that, either. This is not significantly more arcane.
> Then I think we agree.  There's no difference from p=reject and
> p=reject-I-really-mean it.
> > ... If the recipient domain accepts modifications by zero-reputation
> > intermediaries (because there are so many of them, after all)
> I wouldn't call that a reasonable implementation of ARC.  The set of hosts
> that are likely to send you mail with interesting ARC chains is relatively
> small, and I don't think it changes very fast.  Most of the hosts that
> send you non-spam mail aren't going to send you mail that needs ARC.
> If you're setting up a new mailing list host or forwarder, getting
> yourself into whatever whitelists people use will be somewhat painful but
> there's nothing new about that.
> > I’d be interested in other opinions on this. Or whether this is a
> fundamental
> > problem with ARC.
> I'd certainly be interested in hearing how people plan to compile and
> maintain their lists of ARC-worthy hosts.
> Regards,
> John Levine,, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> _______________________________________________
> dmarc mailing list