Re: [dmarc-ietf] ARC vs reject

Michael Thomas <mike@mtcc.com> Sun, 06 December 2020 01:34 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 E9CEB3A03F1 for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 17:34:50 -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 KWqLE0qq3dLo for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 17:34:48 -0800 (PST)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 DBEC23A03EE for <dmarc@ietf.org>; Sat, 5 Dec 2020 17:34:48 -0800 (PST)
Received: by mail-pj1-x102d.google.com with SMTP id hk16so5367017pjb.4 for <dmarc@ietf.org>; Sat, 05 Dec 2020 17:34:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=6535xBrRkvMZwKKwXJuTXQ5V/20MKcxG3jnfR9YsMcI=; b=lR/N9pf5j/adMPD6HV/gWYpbO4Yn64VvLbQiqQNT8Wg8PNeW0Aj3yzBW2oHWE0YFD7 62PbPX7TiWHiuagA44xHlcDtUzbodZ++GDCU7eeyK2MhFBIxwl9MRhlvLT8cc0+biRK1 1fPMD4xXgyeoZq4qtyEHoF1CX70GOBiMpjfFXoCyzkNvbu1q9GvdXcjmDQBeahz47kWQ hkpUoLFTmExcA+xx0nTngZxkXTNXYRO7Ji7MXC7KSEmt7Fb1bmS/X+z8gMg1xgP7Rr+K AESu6mfMNZyxAyHGJRppSi6Evctkw+OCfz4MoT8rl9tr9DvTbyIBQRe8S3n9TTKx7Bpt 9JFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=6535xBrRkvMZwKKwXJuTXQ5V/20MKcxG3jnfR9YsMcI=; b=VXeEsDhKuzHsUePajtP5/hMYQOyepJ1LDD8P9E047BcCz1jZ/4e/ZuZLuVWRR8Jp/v Bn+tAQEDFXlRwEiafmYj4s0psEUe7wcKJB7wUll3lQzZbEzFb80Osv8gnzlUIerjP/4w Szj/iG9H5f3pqbaUQtqd0KeTUjRHNstbOeOvdDN4rhYmG+DxQfc6sy0Oa++cU3jowSiH O+KHOP3s4xUK4U20ZaK1MCiSg0pVxtWMWgLcf0CBFeTCgRIIQZRlBeZXW+sYnku4a0VG +7JE/QCigEO3RZl9xwIGZR5/0N3J2wkzNUyFHpRiHLLYPC5LkQZrE+syLMycti2eysxC Mc5Q==
X-Gm-Message-State: AOAM531FOoqYAwxzCgo/KqEihP2/hdxPtZvnTQT+qXtW6vvd4orxyahq Q8topOgHsuC6j1a5qtMVmzRXXIG+mstjRg==
X-Google-Smtp-Source: ABdhPJwWMGCOo+4WIwsxy6kDzRxvO0uCpfcj7OI9PpDLcOaZd0wiR7PQpapWcXICKem5YnVE1xCrpg==
X-Received: by 2002:a17:90a:8d17:: with SMTP id c23mr10753271pjo.192.1607218487617; Sat, 05 Dec 2020 17:34:47 -0800 (PST)
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id e14sm7824539pgv.64.2020.12.05.17.34.46 for <dmarc@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Dec 2020 17:34:46 -0800 (PST)
To: dmarc@ietf.org
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> <CAH48ZfwHKoVZn9RdhBh-xU=he8=smB59R5EF1TYJ_0upEDHn2A@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <72d32b62-64fb-937a-dac5-6f4c5816f523@mtcc.com>
Date: Sat, 5 Dec 2020 17:34:45 -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: <CAH48ZfwHKoVZn9RdhBh-xU=he8=smB59R5EF1TYJ_0upEDHn2A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------475835F9D0C3D551D804E88B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/4iy_DZu-S9rYO9b-WK5-Bb2u-zE>
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:34:51 -0000

On 12/5/20 5:20 PM, Douglas Foster wrote:
> 1) Michael. you have belabored your questions about DKIM vs ARC rather 
> too long.    It is what it is.


ARC is an experiment. Experiments require peer review.

>
> 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.

DKIM is a mechanism which allows you to be assured that the forwarding 
was done without altering. Since email is more like postcard than a 
letter in an envelope that is a good property.


>
> 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.

Yes, but my bank seriously does not want any "acceptable" 
transformations. There are no acceptable transformations. DMARC needs to 
provide for that use case (and, in fact, it does currently). ARC is 
setting up a situation where there is no way for my bank to say, "no 
way, never".


>
> 4) On the future of ARC:   The idea is harmless
To the contrary security protocols often create unintended consequences. 
The are never "harmless" until proven so. An experiment is hardly 
confidence-inspiring that it has been fully vetted.
>
> 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.

I'm starting to get a little more serious about my quip that the MLM can 
insert a sed script in a header to unmangle the message since it knows 
what transforms it has done, unlike the receiving MTA trying to guess 
the common transformations.

Mike


>
> On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <mike@mtcc.com 
> <mailto: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 <mailto:dmarc@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dmarc
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc