Re: [dmarc-ietf] ARC vs reject

Douglas Foster <dougfoster.emailstandards@gmail.com> Sun, 06 December 2020 01:21 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 06F7D3A09FA for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 17:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uXBEPuLCVAtz for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 17:20:58 -0800 (PST)
Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 C15603A09F9 for <dmarc@ietf.org>; Sat, 5 Dec 2020 17:20:57 -0800 (PST)
Received: by mail-vk1-xa30.google.com with SMTP id h133so1239547vka.6 for <dmarc@ietf.org>; Sat, 05 Dec 2020 17:20:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sTCldYCUR6OiAFpVMPshM3j62nU4g9+76qhK65f+imk=; b=F9Yv0B13iUK0F1wOz/4p5dVYaGu34OQsHoGFWltkoY13LD01ukV6/FSHhrWChsTfdC 1PzkvwXa3Kuahx99muET07BwlnGS+E8iRG7S/0J5kqZlfRo/QnVvmGlVboTlvrYdM9Ec i7QG++A7rCr4y6LPbBrgfB1atzo3a+3wNqx1wB7Gj7UAXG/IYRc+zy1h122GWtr1oDnO BSpkCzpl3uQmcdbd6F85gx/UJKQmZdJpne/oTKg22Cr6mjvEXSid+XRhgHjk5Qf6CTOG /2/3yLZbBIaj/btACh6MVyjlG22kB6DJ6HUn4NINKnr0EKCm5QCjGwI1d8pcankp4jWu EwNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sTCldYCUR6OiAFpVMPshM3j62nU4g9+76qhK65f+imk=; b=AFUMjpXo6JWIIq/imbxXSmIrOxhLy1qu4bxe/RFcqknF2jn4t2vDl7902TxNRvY+/v 1sZqAxM2Jf0yOgDwBjiGulPa54jaLEM7S49tt9SmXKelcfDlNSsvQuIciM9Qp6dtQwqR 5aFGYZrq6CdXXuWy9xH2AxqqKuZF0Msi7EN9SkTZ6EsRYu4QQUDPkAJ8rUhAfAKf0xmZ 3YXURYnVgFyhzIFd4dTAXJB7mT/3Ke1stYCZ7e3MJKJqp/uZX47u5L1weUaDHRgSJjh7 LVnTFFk8OfOf+Ck1Tdu4wf4bV3a2ptNFC1CHFX0uqD8wzZ9t5VXRMDZFdjFRG6qjOQR5 Tpqg==
X-Gm-Message-State: AOAM531SzE5rHyJ91fRwnF6Fac6eyB7Rb0D1ZrcTaQpo2vmXlwV8aKgA uYrt05vWoGZhcHtzmciqcau4BA0RNsp9faX3ieu+4hNL708=
X-Google-Smtp-Source: ABdhPJyp0f0YOlV4JY/c/tdPevmpgoM4S+QGIrdEW7/KnePXwZ6Q6Obe5l/HLXZbmcQ5owN4+Nys6KQWJpHGkvJDRZk=
X-Received: by 2002:a1f:2717:: with SMTP id n23mr9192287vkn.25.1607217656581; Sat, 05 Dec 2020 17:20:56 -0800 (PST)
MIME-Version: 1.0
References: <20201205231059.2BA23290EDCD@ary.qy> <b437a23a-7e7e-f70d-04dc-49810d002c43@mtcc.com> <b6950472-599b-d0a7-c0d1-82db099fb99b@gmail.com> <7ae42764-176d-11a8-e084-b10b6f676944@mtcc.com> <cb526017-c198-44f1-7282-986e5a810d6a@gmail.com> <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com>
In-Reply-To: <8142f18c-ac79-1f94-97d1-2704f0b4ceb6@mtcc.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sat, 5 Dec 2020 20:20:47 -0500
Message-ID: <CAH48ZfwHKoVZn9RdhBh-xU=he8=smB59R5EF1TYJ_0upEDHn2A@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007f511105b5c185f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/s5D4zJzzBSWpdvSF09NPYtDNZe0>
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: Sun, 06 Dec 2020 01:21:00 -0000

1) Michael. you have belabored your questions about DKIM vs ARC rather too
long.    It is what it is.

2) On the issue of "Do Not Forward":  It is certainly an available feature
of postal mail, which the postal service enforces.   Email has no central
authority to reliable enforce such a policy.   Just as importantly, no one
should (and few businesses do) consider email to be an environment where
sensitive information is transmitted.   Any competent bank will send an
email telling you to log into their website to obtain the sensitive
information.   I do not see a "Do Not Forward" policy as something that is
useful or likely to be used.

3) On the issue of p=reject:    You have been usefully pressing the
question of what purpose lies behind the technology.    In the case of
DMARC, the purpose is to block spoofed messages.    We know that mailing
lists turn a legitimate message into a looks-like-spoof message.   ARC is
trying to fix the false spoof, which is a worthy goal.   More precisely, it
is trying to provide information to the recipient system so that the
recipient system can determine that the message is forwarded but not
spoofed.

4) On the future of ARC:   The idea is harmless, but I do not see it
achieving the list-industry goal of eliminating From rewrite.  It actually
reminds me of DKIM without DMARC - a technology looking for an algorithm to
which it can contribute.    Since nobody can articulate how a recipient
uses ARC information to reach an expected conclusion, something important
is still missing.    As I wrote in my last post, I think it fails to
provide enough information for a useful algorithm to be defined.    Even if
that can be solved, there are bigger problems.   We have no algorithm for a
list to know if a particular recipient uses ARC, or whether it will use the
ARC information to draw the desired conclusion about list messages.
 Without those answers, the list is doomed to continue From rewrite even if
when it would not be necessary.    And much of this is about AOL in
particular, and the currently available information suggests that AOL is
not on board with ARC.

5) The work you and Alessandro have done with reverse transformation is
more likely to produce a solution for the mailing lists.   The lists will
continue to do From rewrite, but reverse-transform recipients can validate
the true source of the message and restore the From if desired.

On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <mike@mtcc.com> wrote:

>
> On 12/5/20 4:21 PM, Dave Crocker wrote:
> > On 12/5/2020 3:37 PM, Michael Thomas wrote:
> >> "You can say, no I am smarter than those guys and I REALLY REALLY
> >> mean it, but see 2) above."
> >>
> >> This is really not about questioning my intelligence. eye roll. If I
> >> said the same thing to you, you'd be screaming bloody murder to the
> >> chairs to try to get me banned again.
> >
> > Note that what you have just done is, in fact, an ad hominem and
> > arguably does violate IETF participation rules.
>
> How can me pointing out that you would call that an ad hominem, become
> ad hominem?
>
> This is the bizzarro world that caused me to leave the last time.
>
> >
> > Again, the response you are objecting two exactly followed the
> > linguistic form of the setup you offered.  As such, the response was
> > not directly at you, the author of the posting, but at the
> > hypothetical person you formulated.
>
> Oh yeah, I just missed the implied royal you in the reply directed at me
> from somebody who has a long history of antagonism to me including petty
> 5xx messages from direct mail to him. Whatever was I thinking in the
> Panglossian world we live in?
>
> >
> >> If the publisher of the DMARC record cannot accurately state its
> >> desires/policy, that is a deficiency in the protocol. Reject means I
> >> want you to reject it. It doesn't carve out exceptions. ARC is trying
> >> to carve out exceptions. If it wants an exception, the originating
> >> domain should have a say in whether it desires the receiving domain
> >> to carve out an exception one way or the other.
> >
> > The domain owner might want all sorts of unreasonable things. Having a
> > way to let the domain owner publish demands that are widely ignored
> > indicates a seriously flawed semantic model. And that is, indeed, the
> > current reality for DMARC.
> >
> You are fixated on what the receiver must or must not do. I never said
> anything about that. That is a strawman. I'm pointing out that ARC is
> trying to get two states out of reject where there only is one. It is
> certainly not unreasonable for my bank to say "please reject anything
> that is not by the letter of the law". I don't want somebody to figure
> out how to game all of this ARC stuff to phish me from my bank. That is
> far from unreasonable.
>
> But you can say, no I am smarter than those banks and I REALLY REALLY
> mean it, but I don't care.
>
> Mike
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>